Temporary Document 
Study Group 7

Question 9/7 (Frame relay NNI)

SOURCE*: 	X.76 EDITOR    (TREVOR DAVIES) 

TITLE: 	DRAFT AMENDMENT 1 TO RECOMMENDATION X.76 (SVC Part) 
______________________

ABSTRACT

This document consists of edited pages of draft Amendment 1 to Recommendation X.76 on  Frame Relay  Network-to-Network Interface SVC to be proposed for Resolution 1 approval at the March 1997 SG7 meeting.

Revision bars mark changes to the previous version of draft Recommendation X.76 issued as TD2294+Corr1 at the April 1996 SG7 meeting.

DRAFT AMENDMENT 1 TO RECOMMENDATION X.76 (SVC Part) (References to be merged with X.76 PVC Part)

2	References

[ ]	ITU-T Recommendation E.160 (193), Definitions relating to national and international numbering plans.

[ ]	ITU-T Recommendation E.164 (08/91) Numbering plan for the ISDN era.

[ ]	ITU-T Recommendation E.166 (10/92)/X.122 (09/92), Numbering plan interworking for the E.164 and X.121 numbering plans.

[ ]	ITU-T Recommendation X.121 ( 09/92) International numbering plan for public data networks.

[ ]	ITU-T Recommendation Q.951 (03/93), Stage 3 service description for number identification supplementary services using DSS1.

[ ]	ITU-T Recommendation Q.850 (1993),  Usage of cause and location in DSS 1 and SS7 ISUP.

[ ]	ITU-T Recommendation Q.921 (1993),  ISDN UNI - data link signaling specification.

[ ]	ITU-T Recommendation Q.922 (02/92),  ISDN data link specification for frame mode bearer  services.

[ ]	ITU-T Recommendation Q.931 (03/93), DSS1 Signaling Specification for basic Call Control.

[ ]	ITU-T Recommendation Q.933 (03/93), DSS1 Signaling Specification for Frame Mode Basic Call Control.

[ ]	ITU-T Recommendation T.50 (09/92) International Reference Alphabet (IRA).

[ ]	ITU-T Recommendation X.36 (1995), Interface between a DTE and a DCE for public data networks providing frame relay data transmission service by dedicated circuit (PVC part).

[ ]	Amendment 1 to ITU-T Recommendation X.36 (1996), Interface between a DTE and a DCE for public data networks providing frame relay data transmission service by dedicated circuit. (SVC part)

3 	Definitions (to be merged with X.76 PVC part)

• Connected DLCI: A DLCI is "connected" when it is being used in a frame relay switched virtual circuit.

• Released DLCI: A DLCI is "released" when it is not being used in a frame relay switched virtual circuit but is available for use in a new frame relay switched virtual circuit.

4	Abbreviations (to be merged with X.76 PVC part)

LAPF		Link Access Protocol F
SPVC		Switched permanent virtual circuit
SVC		Switched Virtual Circuit

10		Frame relay SVC signalling
10.1	General 
This clause defines the signalling to support frame relay switched virtual circuits (SVC) at the network-to-network interface (NNI). It defines also the following additional facilities: 

• Transit network identification
• Call identification
• Closed user group interlock code
• Reverse charging indication
• Clearing network identification
• Transit network selection
• Frame transfer priority (for further study)

As the signalling at the NNI for frame relay SVC is applicable to Integrated Services Digital Networks  (ISDN) supporting Recommendation Q.933 at the user-network interface and Public Data Networks supporting Recommendation X.36 at the DTE/DCE interface, the following terminology is used: 

• The calling user/DTE is connected to a public network at the calling UNI or DTE-DCE interface. 

• The called user/DTE is connected to a public network at the called UNI or DTE-DCE interface. 

• At the NNI, an originating network is the network to which the calling DTE/user is attached.

• A terminating network is a network to which the called DTE/user is attached.

 • A transit network is an intermediate network connected to at least two other networks. 

• A calling STE is an STE initiating a frame relay SVC or call establishment and a called STE is an STE receiving a request to establish a frame relay call. 

• The forward direction is the direction from the calling to the called user/DTE. The backward direction is the direction from the called to the calling user/DTE. This convention is shown in Figure 10.1/X.76.

FIGURE 10-1/X.76
Convention used for SVC signalling

10.2 Signalling Channel
Recommendation Q.922 defines the link layer protocol known as LAPF to provide a reliable data link connection for the exchange of SVC signalling messages defined in this clause across a frame relay NNI.

FIGURE 10-2/X.76
STE/STE protocol layers for signalling

The following frame types are identified in Q.922 and defined in Q.921 must be supported:

• Set asynchronous balanced mode extended (SABME) command
• Disconnection (DISC) command
• Receive ready (RR) command and response
• Reject (REJ) command/response
• Receive not ready (RNR) command/response
• I frames
• Unnumbered acknowledgment (UA) response
• Disconnected mode (DM) response
• Frame reject (FRMR) response

XID frames are not used and Unnumbered Information (UI) frames are used for PVC signalling. SVC signalling does not affect PVC signalling since for SVC signalling, I frames are used whereas for PVC signalling UI frames are used.

In order to exchange SVC signalling messages across the NNI a LAPF link has to be established using DLCI=0. After establishment of LAPF link, the data link connection identified with DLCI=0 is automatically ready for the exchange of the signalling messages across the NNI. This LAPF link is known as the signalling channel.

On the signalling channel, FECN, BECN and DE bits are not used. They must be set to 0 upon transmission and must not be interpreted upon reception.

10.3	State definitions

10.3.1  Frame relay call states at the NNI
The following states are the states that may exist at either side of a frame relay NNI. These states are derived from Recommendations Q.933 and X.36 states used at the network side of a UNI and use the equivalent state numbers.  

Null state (NN0). No switched virtual circuit exists.

Call initiated (NN1). This state exists for a called STE after it has received a call establishment request from the calling STE but has not responded yet.

Call proceeding sent (NN3). This state exists  for a  called STE when it has acknowledged the receipt of the information necessary to establish a call. 

Call delivered (NN4). This state exists for a called STE after it has sent an indication to the calling STE that called user alerting has been initiated. This state is used only by networks supporting Recommendation Q.933 at the UNI.

Call present (NN6). This state exists for an calling STE after it has send a call establishment request to the called STE but has not received a response. 

Call received (NN7). This state exists for a calling STE after it has received an indication from the called STE that called user alerting has been initiated.  This state is used only by networks supporting Recommendation Q.933 at the UNI.  

Call proceeding received (NN9). This state exists for a calling STE when it has received an acknowledgment that the called STE received the call establishment request.

Active (NN10). This state exists when the Frame relay SVC has been established and data transfer phase may begin.

Release request (NN11). This state exists for a STE when it has sent a request to release the SVC.

Release indication (NN12). This state exists for a STE when it has received a request to release the SVC and is waiting for a response.

10.3.2 	States associated with restart
The following states are associated with restart:

Restart null (Rest0). No restart request exists.

Restart request (Rest1). This state exists for one STE after it has sent a restart request to the other STE and is waiting for an acknowledgment.

Restart (Rest2). This state exists for one STE when it has received a request for a restart and has not returned an acknowledgment indicating the outcome of the restart.

10.4		Message definitions
The following messages are used at the Frame Relay NNI:

-	Alerting.This message is used only by networks supporting Recommendation Q.933 at the UNI.  

-	Call proceeding

-	Connect

-	Progress. This message is used only by networks supporting Recommendation Q.933 at the UNI.  

-	Release

-	Release Complete

-	Restart

-	Restart Acknowledge

-	Setup

-	Status

-	Status Enquiry

Each message is described in this section as follows:

• A brief definition of the purpose of the message 

• The message structure and content

• The "significance" of the message:

• Local significance means that the message is applicable only at the NNI.

• Global significance means that the message is applicable to the two UNIs and the NNIs. involved in the call. 

• The direction in which the message may be sent: "both" means the message can be sent by either side of the NNI. "Forward" means the message is send only by the calling STE  to the called STE and "backward" refers to the opposite direction.

• A table listing the information elements in the order of their appearance in the message. For each information element, the table indicates:

• The section describing the information element.

• Whether the information element inclusion in the message is mandatory (M), or optional (O), with a reference to notes explaining the circumstances under which the information element shall be included.

• The length of the information element (or permissible range of length) in octets. * denotes an undefined length which may be network or service dependent.

• Further explanatory notes as necessary.

10.4.1	Alerting
This message is sent by the called STE to the  calling STE to indicate that called user alerting has been initiated at the UNI. This message is used only by networks supporting Recommendation Q.933 at the UNI.

Message type: ALERTING			Direction: Backward
Significance: global

TABLE 10-1/X.76

ALERTING message content   

INFORMATION ELEMENT	REFERENCE	TYPE	LENGTH	
Protocol discriminator	10.5.1	M	1	
Call reference	10.5.2	M	3	
Message type	10.5.3	M	1	
Progress Indicator	10.5.23	O (NOTE 1)	2-4	
User-user	10.5.28	O (NOTE  2)	2-131	
NOTE 1 - This information element is used only by networks supporting Recommendation Q.933 at the UNI.

NOTE 2 - This information element is passed on transparently at the NNI.				

10.4.2	Call proceeding
This message is sent by the called STE to the calling STE to indicate that the requested call establishment has been initiated. This message acknowledges the receipt of the SETUP message.

Message type: CALL PROCEEDING		Direction: Backward
Significance: local

TABLE 10-2/X.76 

CALL PROCEEDING message content   

INFORMATION ELEMENT	REFERENCE	TYPE	LENGTH	
Protocol discriminator	10.5.1	M	1	
Call reference	10.5.2	M	3	
Message type	10.5.3	M	1	
Data Link Connection Id. 	10.5.16	 M 	4-6	

.
10.4.3	Connect
This message is sent by the called STE to the calling STE to indicate that the called user/DTE has accepted the call.

Message type: CONNECT			Direction: Backward
Significance: global

TABLE 10-3/X.76  

CONNECT message content   

INFORMATION ELEMENT	REFERENCE	TYPE	LENGTH	
Protocol discriminator	10.5.1	M	1	
Call reference	10.5.2	M	3	
Message type	10.5.3	M	1	
Progress Indicator	10.5.23	O (NOTE 1, 2)	2-4	
End-to-end transit delay	10.5.17	O (NOTE 1)	2-11	
Packet layer binary param.	10.5.22	O (NOTE 1, 2)	2-3	
Link layer core param.	10.5.19	M (NOTE 3)	2-27	
Link layer protocol param.	10.5.20	O (NOTE 1, 2)	2-9	
Connected number	10.5.14	O (NOTE 4)	2-19	
Connected sub-address	10.5.15	O (NOTE 2)	2-23	
X.213 priority	10.5.29	O (NOTE 1, 2)	2-8	
Transit Network Identification	10.5.26	O (NOTE 5)	5-11	
Low layer compatibility	10.5.20	O (NOTE 1, 2)	2-16	
User-user	10.5.28	O (NOTE 2)	2-131	
NOTE 1 - The support of this information element is a network option.This information element is used only by networks supporting Recommendation Q.933 at the UNI.

NOTE 2 - This information element is passed on transparently at the NNI.

NOTE 3 - Included to indicate the final link layer core parameters to use for the SVC. 

NOTE 4 - Included if it was included by the called user/DTE at the called UNI/DTE-DCE interface.

NOTE 5 -This information element may be repeated to identify multiple networks. See § 10.6.9 .1.

10.4.4	Progress
This message is sent by the called STE to the calling STE  to indicate the progress of a call. This message is used only by networks supporting Recommendation Q.933 at the UNI.

Message type: PROGRESS			Direction: Backward
Significance: global

TABLE 10-4/X.76  

PROGRESS message content   

INFORMATION ELEMENT	REFERENCE	TYPE	LENGTH	
Protocol discriminator	10.5.1	M	1	
Call reference	10.5.2	M	3	
Message type	10.5.3	M	1	
Progress Indicator	10.5.23	M (NOTE 1)	4	
NOTE 1 - This information element is passed on transparently at the NNI.	

10.4.5	Release
This message is sent to indicate that the SVC has been cleared and the data link connection identifier and call reference are being released.

Message type: RELEASE			Direction: Both
Significance: global

TABLE 10-5/X.76 

RELEASE message content   

INFORMATION ELEMENT	REFERENCE	TYPE	LENGTH	
Protocol discriminator	10.5.1	M	1	
Call reference	10.5.2	M	3	
Message type	10.5.3	M	1	
Cause	10.5.11	M (NOTE 1)	2-32	
Connected number	10.5.14	O (NOTE 2, 3)	2-19	
Connected sub-address	10.5.15	O (NOTE 3, 4)	2-23	
Clearing Network Identification	10.5.12	O	5-11	
Transit Network Identification	10.5.26	O (Note 5)	5-11	
User-user	10.5.28	O (NOTE 3, 4)	2-131	
NOTE 1 - This information element may  occur twice to indicate multiple release causes.

NOTE 2 - Included to indicate the called number requesting to release the SVC.

NOTE 3 - The support of this information element is a network option. This information element is used only by networks supporting Recommendation Q.933 at the UNI.

NOTE 4 - This information element is passed on transparently at the NNI.

NOTE 5 -This information element may be repeated to identify multiple networks. See § 10.6.9. 1

10.4.6	Release Complete
This message is sent to indicate that the SVC has been cleared and the data link connection identifier and call reference has been released. Normally this message is sent as a reply to a RELEASE message.

Message type: RELEASE COMPLETE			Direction: Both
Significance: local (NOTE 1)

NOTE 1: This message has local significance. However, it has a global significance when it is used as the first call clearing message.

TABLE 10-6/X.76 

RELEASE COMPLETE message content   

INFORMATION ELEMENT	REFERENCE	TYPE	LENGTH	
Protocol discriminator	10.5.1	M	1	
Call reference	10.5.2	M	3	
Message type	10.5.3	M	1	
Cause	10.5.11	O (NOTE 1)	2-32	
Connected number	10.5.14	O (NOTE 2, 3)	 2-19	
Connected sub-address	10.5.15	O (NOTE 3, 4)	2-23	
Clearing Network Identification	10.5.12	O	5-11	
Transit Network Identification	10.5.26	O (NOTE 5)	5-11	
User-user	10.5.28	O (NOTE 3, 4)	2-131	
NOTE 1 - Mandatory if this message is the first clearing message. This information element may occur twice to indicate multiple release causes.

NOTE 2 - Included to indicate the called number requesting to release the SVC.

NOTE 3 - The support of this information element is a network option. This information element is used only by networks supporting Recommendation Q.933 at the UNI.

NOTE 4 - This information element is passed on transparently at the NNI.

NOTE 5 -This information element may be repeated to identify multiple networks. See § 10.6.9.1

10.4.7	Restart
This message is sent to initiate restart (i.e. return to an idle condition) the NNI.

Message type: RESTART		Direction: Both
Significance: local

TABLE 10-7/X.76 

RESTART message content   

INFORMATION ELEMENT	REFERENCE	TYPE	LENGTH	
Protocol discriminator	10.5.1	M	1	
Call reference	10.5.2	M (NOTE 1)	3	
Message type	10.5.3	M	1	
Restart indicator	10.5.24	O (NOTE 2)	3	
NOTE 1 - Only the global call reference value is used with this message.

NOTE 2 - .This information element is optional when the restart applies to all SVCs in the same interface as the signalling channel. Otherwise it is mandatory. 	

10.4.8	Restart Acknowledge
This message is sent to indicate that the requested restart has been completed.

Message type: RESTART ACKNOWLEDGE		Direction: Both
Significance: local

TABLE 10-8/X.76 

RESTART ACKNOWLEDGE message content   

INFORMATION ELEMENT	REFERENCE	TYPE	LENGTH	
Protocol discriminator	10.5.1	M	1	
Call reference	10.5.2	M (NOTE 1)	3	
Message type	10.5.3	M	1	
NOTE 1 - Only the global call reference value is used with this message.	

10.4.9	Setup
This message is sent by the calling STE to the called STE to initiate SVC establishment.

Message type: SETUP			Direction: Forward
Significance: global

TABLE 10-9/X.76  

SETUP message content   

INFORMATION ELEMENT	REFERENCE	TYPE	LENGTH	
Protocol discriminator	10.5.1	M	1	
Call reference	10.5.2	M	3	
Message type	10.5.3	M	1	
Bearer capability	10.5.4	M	5	
Data Link Connection Id. 	10.5.16	M 	4-6	
Progress Indicator	10.5.23	O (NOTE 1, 2)	2-4	
End-to-end transit delay	10.5.17	O (NOTE 1)	2-11	
Packet layer binary param.	10.5.22	O (NOTE 1,2)	2-3	
Link layer core param.	10.5.19	M	2-27	
Link layer protocol param.	10.5.20	O (NOTE 1, 2)	2-9	
Reverse Charging indication	10.5.25	O	3	
X.213 priority	10.5.29	O (NOTE 1, 2)	2-8	
Transit Network Identification	10.5.26	O(NOTE 3)	5-11	
CUG interlock code	10.5.13	O 	12-16	
Call Identification	10.5.5	M	6	
Calling party number	10.5.9	M	2-19	
Calling party subaddress	10.5.10	O (NOTE 2)	2 -23	
Called party number	10.5.7	M 	2-18	
Called party subaddress	10.5.8	O (NOTE 2)	2 - 23	
Transit Network Selection	10.5.27	O (NOTE 3,4) 	5-11	
Low layer compatibility	10.5.21	O (NOTE 2)	2 - 16	
High layer compatibility	10.5.18	O (NOTE 1, 2)	2-4	
User-user	10.5.28	O (NOTE 2)	2-131	
NOTE 1 - The support of this information element is a network option.This information element is used only by networks supporting Recommendation Q.933 at the UNI.

NOTE 2 - This information element is passed on transparently at the NNI.

NOTE 3 - This information element may be repeated to identify multiple networks. See § 10.6.9.1 and §10.6.9.6

NOTE 4 -  The support of this information element is a network option.

10.4.10	Status
This message is sent in response to a STATUS ENQUIRY or at any time during a call to report certain error conditions.

Message type: STATUS			Direction: Both
Significance: local

TABLE 10-10/X.76 

STATUS message content   

INFORMATION ELEMENT	REFERENCE	TYPE	LENGTH	
Protocol discriminator	10.5.1	M	1	
Call reference	10.5.2	M	3	
Message type	10.5.3	M	1	
Cause	10.5.11	M	4-32	
Call State	10.5.6	M	3	

10.4.11	Status Enquiry
This message is sent at any time to solicit a STATUS message.

Message type: STATUS ENQUIRY		Direction: Both
Significance: local

TABLE 10-11/X.76 

STATUS ENQUIRY message content   

INFORMATION ELEMENT	REFERENCE	TYPE	LENGTH	
Protocol discriminator	10.5.1	M	1	
Call reference	10.5.2	M	3	
Message type	10.5.3	M	1	

10.5  General message format and information element coding
This section describes the information elements which are included in the  signalling messages defined in the previous section.

Every message of this protocol shall consist of the following parts:
a) protocol discriminator;
b) call reference;
c) message type;
d) other information elements

Information elements a), b), c) are common to all the messages and shall always be present. Each message will have additional information elements. This  organization is shown in Figure 10.3/X.76.

Unless specified otherwise, a particular information element may be present only once in a given message. 

FIGURE 10-3/X.76
General message organization example

The following variable length information elements are used for frame relay switched virtual circuit:

		Information element  			I.E. identifier coding
		
		-Bearer Capability				0000 0100 
		-Call Identification				0110 1001
		-Call State					0001 0100
		-Called party number				0111 0000
		- Called party SPVC				0000 1010
		-Called party sub-address			0111 0001
		-Calling party number			            0110 1100
		-Calling party sub-address			0110 1101
		-Cause					            0000 1000
		-Clearing Network Identification                    TBD
		-Closed user group interlock code		0110 1000
		-Connected party number			0100 1100
		-Connected party sub-address		            0100 1101
		-Data link connection identifier (DLCI)	0001 1001
		-End-to-end transit delay			0100 0010
		-High layer compatibility			0111 1101
		-Link layer core parameters			0100 1000
		-Link layer protocol parameters		0100 1001
		-Low layer compatibility			0111 1100
		-Packet layer binary parameters		0100 0100
		-Progress indicator				0001 1110
		-Restart indicator				0111 1001
		-Reverse charging indication			0100 1010
		-Transit Network identification		0110 0111
		-Transit network selection			0111 1000
		-User-user					0111 1110
		-X.213 priority				0101 0000

The coding of the information elements other than the first three mandatory information elements (protocol discriminator, call reference and message type) is as follows:

• The information elements used with frame relay call control are of variable length. They are described in alphabetical order. However, there is a particular order of appearance for each information element in a message. The code values of the variable length information element identifiers are assigned in numerical order according to the actual order of appearance of each information element in a message. This allows a receiver to detect the presence or absence of a particular information element without scanning through the entire message.

• Information element identifier values (first octet of a variable length information element) with bits 5-8 coded "0000" are for information elements for which comprehension by the receiver is required.

• When the description of the information elements contains spare bits, these bits are indicated as being set to "0". 

• The second octet of a variable length information element indicates the total length of the contents starting with octet 3. It is the binary coding of the number of octets of the contents, with bit 1 as the least significant bit.

• Each octet of a variable length information element is numbered. 

• Optional octet (s) are marked with asterisks (*).

• An octet group is a self contained entity, it contains one or more octets. For frame relay information elements, the internal structure of an octet group is defined by using the following extension mechanism:

• The first octet of an octet group is identified by a number (N). The subsequent octets are identified as Na, Nb, Nc,....Bit 8 of each octet is the extension bit. The value "0" of bit 8 indicates that the octet group continues to the next octet. The value "1" of bit 8 indicates that this octet is the last octet of the octet group. if one octet (Nc) must be present, the preceding octets (N, Na and Nb) must also be present.

• In the description of the information elements, bit 8 is marked "0/1 ext" if another octet follows. Bit 8 is marked "1 ext" if this is the last octet of the octet group.

• When a field extends over more than one octet, the order of bit values progressively decreases as the octet number increases. The least significant bit of the field is represented by the lowest numbered bit of the highest-numbered octet of the field.

10.5.1	Protocol discriminator
The protocol discriminator is the first part (first octet) of every message. It is coded as shown in Figure 10.4/X.76.

	

FIGURE 10-4/X.76
Protocol discriminator

10.5.2	Call reference

The purpose of the call reference is to identify the switched virtual circuit to which the particular message applies. The call reference does not have end-to-end significance. The call reference is the second part of every message.

The call reference is coded as shown in Figure 10.5/X.76. Only call reference values of two octets (15 bits) are supported in this Recommendation. The encoding of the call reference value always uses two octets even if the value can be encoded in one octet only. Hence, the length field will always have a binary value of '0010'. The most significant bit of the call reference value is bit 7 of octet 2 and the least significant bit is bit 1 of octet 3. 

The purpose of the call reference flag is to identify who allocated the call reference value for a call. The call reference flag is used to resolve simultaneous attempts to allocate the same call reference value.

The call reference flag can take the binary values '0' or '1'. The call reference flag is used to identify which end of the NNI originated a call reference. The origination side always sets the call reference flag to '0'. The recipient side always sets the call reference flag to '1'.

The call reference value will always have two octets. The call reference value is coded as a 15-bit binary number. A call reference value equal to zero is reserved for the global call reference value. The global call reference has also a length of 2 octets. 

	
FIGURE 10-5/X.76

Call reference information element

TABLE 10-12/X.76  

Call reference information element   

Bit (octet 2)
 8 
0	The message is sent from the side of the NNI that originates the call reference.
1	The message is sent to the side of the NNI tthat originates the call reference.

10.5.3	Message type
The following messages are used at the NNI:

	Message type				Message type code point
	
	• ALERTING					0000 0001
	• CALL PROCEEDING			0000 0010
	• CONNECT					0000 0111
	• PROGRESS				            0000 0011
	• SETUP					0000 0101
	• RELEASE					0100 1101
	• RELEASE COMPLETE			0101 1101
	• RESTART					0100 0110
	• RESTART ACKNOWLEDGMENT   	0100 1110
	• STATUS					0100 1110
	• STATUS ENQUIRY			0111 0101

10.5.4	Bearer capability
The purpose of the bearer capability information element is to request a bearer service. The only bearer service supported is the Frame Relay bearer service. The bearer capability information element is coded as shown in Figure 10.6/X.76.

Note - Octet numbering is according to Recommendation Q.931
FIGURE 10-6/X.76

Bearer Capability information element

TABLE 10-13/X.76  

Bearer capability information element   

User information layer protocol (octet 6)
Bits 
5 4 3 2 1
0 1 1 1 0	Recommendation Q.922 (NOTE) 
0 1 1 1 1	Core aspects of frame mode (Annex A of Q.922)
All other values are reserved
NOTE: The support of the capability identified by this code point is a network option.

10.5.5	Call identification

The Call identitfication is a used to uniquely identify a call.

FIGURE 10-7/X.76
Call identification information element

10.5.6	 Call state
The call state information element is used to describe the state of a call. 

FIGURE 10-8/X.76
Call state information element

TABLE 10-14/X.76  

Call state information element   

Call state value (octet 3)
Bits 
6 5 4   3 2 1		State
0 0 0   0 0 0		NN0	 Null
0 0 0   0 0 1		NN1	Call initiated
0 0 0   0 1 1		NN3	Call proceeding sent
0 0 0   1 0 0		NN4	Call delivered
0 0 0   1 1 0		NN6	Call present
0 0 0   1 1 1		NN7	Call received
0 0 1   0 0 1		NN9	Call proceeding received
0 0 1   0 1 0		NN10	Active
0 0 1   0 1 1		NN11	Release request
0 0 1   1 0 0		NN12	Release indication
1 0 0   0 0 0		Rest0	Null
1 0 0   0 0 1		Rest1	Restart request
1 0 0   0 1 0		Rest2	Restart

10.5.7	Called party number

The purpose of the Called party number information element is to identify the called party of a call.

FIGURE 10-9/X.76
Called party number information element

TABLE 10-15/X.76  

Called party number information element   

Type of number (octet 3)
	Bits 
	7 6 5
	0 0 1		International number (NOTE 2 1)
	All other values are reserved.

NOTE 1 -  Prefix or escape digits shall not be included in the number digits.

Number plan identification (octet 3)
	Bits 
	4 3 2 1
	0 0 0 1		ISDN/telephony numbering plan (Rec. E.164)
	0 0 1 1		Data numbering plan (Rec. X.121) 
	All other values are reserved.

Valid combinations of type of number and numbering plan fields:

	    TON		NPI			Format
	• Internat.		E.164			CC+N(S)N
	• Internat.		 X.121		DNIC+NTN

Number digits (octet 4 etc.)
The number digits appear in multiple octets starting at octet 4. One digit is coded per octet such that the leftmost digit is coded in octet 4. Each digit is coded according to Recommendation T.50.

10.5.8	Called party subaddress

The purpose of the Called party subaddress information element is to identify the subaddress of the called party of the call. This information element is passed on transparently at the NNI.

FIGURE 10-10/X.76
Called party subaddress information element

10.5.9	Calling party number

The purpose of the Calling party number information element is to identify the origin of a frame relay switched virtual circuit.

FIGURE 10-11/X.76
Calling party number information element

TABLE 10-16/X.76  

Calling party information element   

Type of Number (octet 2) 
0 0 1		International number (NOTE 2 1)
All other values are reserved.

NOTE 1 - Prefix or escape digits shall not be included in the number digits.

Number plan identification (octet 3)
Bits 
4 3 2 1
0 0 0 1		ISDN/telephony numbering plan (Rec. E.164)
0 0 1 1		Data numbering plan (Rec. X.121) 
All other values are reserved.

Valid combinations of type of number and numbering plan fields:

TON		NPI			Format
• International		E.164			CC+N(S)N
• International		 X.121		DNIC+NTN
The other combinations are invalid. 

Number digits (octet 4 etc.)
The number digits appear in multiple octets starting at octet 4. One digit is coded per octet such that the leftmost digit is coded in octet 4. Each digit corresponds to a character coded according to Recommendation T.50.

Presentation indicator (octet 3a)
	Bits 
	7 6 
	0 0		Presentation allowed 
	All other values are reserved.

Screening indicator (octet 3a)
	Bits 
	2 1
	0 1		User provided verified and passed (NOTE 1)

	1 1		Network provided 
All other values are reserved.

NOTE 1 - Since in some cases the network cannot guarantee that the complete number identifies the calling DTE, the term "verified" implies matching the user provided number or part of this number with the range(s) of numbers stored at the network. It implies also at least a valid format of user provided number information. 

Number digits (octet 4 etc.)
The number digits appear in multiple octets starting at octet 4. One digit is coded per octet such that the leftmost digit is coded in octet 4. Each digit corresponds to a character coded according to Recommendation T.50.

10.5.10	Calling party subaddress

The purpose of the Calling party subaddress information element is to identify the subaddress of the originator of the frame relay call. This information element is passed on transparently at the NNI.

FIGURE 10-12/X.76
Calling party subaddress information element

10.5.11	Cause
The purpose of the Cause information element is to identify an event that occured to a frame relay SVC, a DTE/DCE interface or the frame relay network and to provide a reason for clearing a frame relay SVC. The cause information element is coded as shown in Figure 10-13/X.76 and Table 10-17/X.76. Annex B/X.76 provides detailed information on the use and coding of the Cause information element fields. The Cause information element may be repeated once.

FIGURE 10-13/X.76
Cause information element

TABLE 10-17/X.76 

Cause information element   

Location (octet 3) (See Subsection 4.3.10.1 on Location field generation)
Bits
4 3 2 1 
0 0 0 0		user (U)
0 0 0 1		private network serving the local user (LPN)
0 0 1 0		public network serving the local user (LN)
0 0 1 1		transit network (TN)
0 1 0 0		public network serving the remote user (RLN)
0 1 0 1		private network serving the remote user (RPN)
0 1 1 1		international network (INTL)
1 0 1 0		network beyond interworking point (BI)
All other values are reserved.

Mapping Cause location at the NNI (octet 3):
The location "Private network serving the local user" or "Public network serving the local user" should not be sent across the frame relay NNI. The conversion from "Private network serving the local user" to "Private network serving the remote user" or "Public network serving the local user" to "Public network serving the remote user" shall take place in the network generating the cause. 

In all other cases the location indicator shall be passed unchanged.

Recommendation  (octet 3a bits 1 t o 7)
Bits
7 6 5 4 3 2 1 
0 0 0 0 0 0 0		Q.931
0 0 0 0 1 1 1		X.76
All other values are reserved

Cause value (octet 4 bits 1 t o 7)
The cause value is divided into two fields, a class (bit 5 to 7) and a value within the class (bits 1 to 4). The class indicates the general nature of the event:

Octet 4 
Bits
7 6 5
0 0 0		Normal event
0 0 1		Normal event
0 1 0 		Resource unavailable
0 1 1		Service or option not available
1 0 0		Service or option not implemented
1 0 1		Invalid message 
1 1 0		Protocol error
1 1 1		Interworking

See Annex B of Recommendation X.76 for the cause values.

• Diagnostic(s)  (octet 5): See Annex B/X.76 on Coding of the diagnostic field for the relevant diagnostic codes.

10.5.12	Clearing Network Identification

The purpose of this information element is to identify the network responsible for clearing of a call.

FIGURE 10-14/X.76
Clearing Network Identification information element

TABLE 10-18/X.76

Clearing Network Identification information element   

Network identification plan (octet 3)
bits
4 3 2 1 
0 0 1 0	Network identification using E.164 Country code (NOTE 1)
0 0 1 1	Data network identification code (Recommendation X.121)
All other values are reserved.

NOTE 1 - This code point is used to identify public frame relay networks numbered under the E.164 numbering plan (See Appendix VI). The network identification consists of an E.164 Country Code followed by a network number. The maximum size is 8 octets.

Network identification (octet 4)
These characters coded according to Recommendation T.50 are organized according to the network identification plan specified in octet 3.

10.5.13	Closed user group interlock code
The purpose of the Closed user group interlock code information element is to indicate the interlock code of the closed user group to be used for the call and the type of access selection.

FIGURE 10-15/X.76
Closed user group interlock code information element

TABLE 10-19/X.76 (CONT) 

Closed user group interlock code information element   

CUG indication (octet 3)
Bits 
3 2 1 
0 0 1	Closed user group selection
0 1 0	Closed user group with outgoing access selection and indication

Interlock code (IC) indicator (octet 3)
Bits 
5 4 
0 1	DNIC interlock code 
1 0	Interlock coded using E.164 country code

CUG interlock code (octet 4 etc.)
The CUG interlock code is represented by  a variable number of octets encoded according to Recommendation T.50. The CUG interlock coded consist of a network identification as specified in the Network identification information element and a closed user number with fixed length of 5 octets. These two components guarantee the uniqueness of the interlock code globally and within the assigning network.

10.5.14	Connected number
The purpose of the connected number is to identify the responding party of the call. The coding of the Connected number information element is the same as the coding of the Calling party number information element.

FIGURE 10-16/X.76
Connected number information element

10.5.15	Connected subaddress
The purpose of the connected sub-address is to identify the subaddress of the responding user/DTE of a call. This information element is carried it transparently at the NNI. 

FIGURE 10-17/X.76
Connected subaddress information element

10.5.16	Data link connection identifier
The Data Link Connection Identifier information element identifies the Data link connection identifier (DLCI) selected or assigned and the selection option.

The DLCI is coded as shown in Figure 10.17/X.76. The default length of the DLCI values is two octets (10 bits). By bilateral agreements, some networks may support DLCI length of three or four octets. 

NOTES
1	The standard default length of the DLCI is two octets.

2 	Bit 6 of octet 3 is the most significant bit in the DLCI.

3 	This octet shall be included only when bilateral agreements allows a three octet DLCI (16 bits).

4 	These octets shall both be included only when bilateral agreements allow a four  octet DLCI (23 bits).

FIGURE 10-18/X.76
Data link connection identifier information element

TABLE 10-19/X.76 

Data link connection identifier information element   

Pref/Excl (octet 3)
Bits 
7 
1 		Exclusive, only the indicated DLCI is acceptable
All other values are reserved

Data link connection identifier (octet 3 and 3a, optionally 3b and 3c) 

Data link connection identifier is coded as a binary number.

10.5.17	End-to-end transit delay
The purpose of the End-to-end transit delay is to request and indicate the maximum transit delay for the SVC. Transit delay is the end-to-end one-way transit delay for frame relay data transfer phase between the calling user/DTE and the called user/DTE. 

The support of this information element is a network option. This information element is used only by networks supporting Recommendation Q.933 at the UNI. The definition of the End-to-end transit delay fields is in Recommendation Q.933. 

FIGURE 10-19/X.76
End-to-end transit delay

10.5.18	High layer compatibility
The purpose of the high layer compatibility information element is to provided a means to be used by the remote user for compatibility checking. The support of this information element is a network option. If it is supported, the high layer compatibility information element is passed on transparently at the NNI.

FIGURE 10-20/X.76
High layer compatibility information element

10.5.18	Link layer core parameters
The purpose of the link layer parameters information element is to indicate the requested frame relay quality of service parameters to be used for the frame relay SVC. The term "outgoing" used at the UNI should be interpreted to mean "forward direction" at the NNI and "incoming" should be interpreted to mean "backward direction" at the NNI.

FIGURE 10-21/X.76
Link layer core parameters information element

TABLE 10-20/X.76

Link layer core parameters information element

Maximum frame mode information field (Octet group 3):
The maximum frame mode information field, when present,  follows the address field and precedes the frame check sequence field. The default maximum size is 1600 octets.

If the maximum frame mode information field is symmetrical (same size in the incoming and outgoing directions) octets 3c and 3d are not coded and the value in octets 3a and 3b are used for both directions.

Throughput (Octet group 4): The throughput (also known as CIR or Committed Information Rate) is the average number of bits of the frame mode information field transferred per second across the NNI in one direction. The throughput is measured over an interval of duration "T" known also as the Committed rate measurement interval (Tc).

The throughput can be asymmetrical if the values in the incoming and outgoing directions differ. If the throughput is symmetrical, octets 4c and 4d are not coded and the value in octets 4a and 4b are used for both directions.

Minimum acceptable throughput (Octet group 5):
The purpose of the minimum acceptable throughput is to negotiate the throughput of the call. Minimum acceptable throughput is the lowest throughput value the calling user is willing to accept for the call.

This field which is present only in the SETUP message is carried unchanged through the network(s). Its value may not be greater than the requested throughput (octet group 4).

The minimum acceptable throughput can be asymmetrical (the values in the incoming and outgoing directions differ). If the minimum acceptable throughput is symmetrical, octets 5c and 5d are not coded and the value in octets 4a and 4b are used for both directions.

Throughput and minimum acceptable throughput are expressed as an order of magnitude (in powers of 10) and an integer multiplier. The multiplier shall be encoded as the smallest possible number. For example a throughput of 64 kbit/s shall be expressed as 64 x 103 and not 640 x 102.

TABLE 10-20/X.76 (CONT.)

Link layer core parameters information element

Magnitude (octet 4a, 4c, 5a and 5c)
	Bits 
	7 6 5 
	0 0 0		100
	0 0 1		101
	0 1 0		102
	0 1 1		103
	1 0 0		104
	1 0 1		105
	1 1 0		106
	All other values are reserved

Multiplier (octet 4a, 4b, 4c, 4d, 5a, 5b, 5c, and 5d)
This field indicates in binary the value by which the magnitude shall be multiplied to obtain the throughput and the minimum acceptable throughput.

Committed burst size (Octet group 6):
This field indicates the maximum amount of data (in bits) that the network agrees to transfer over the measurement interval T. This data may appear in one or more frames possibly with inter-frame idle flags.

This field specifies a number of octets. Therefore the committed burst size is 8 x the contents of this field. If the committed burst size is symmetrical, octets 6c and 6d are not coded and the value in octets 6a and 6b are used for both directions.

Excess burst size (Octet group 7):
This field indicates the maximum amount of uncommitted data (in bits) that the network will attempt  to deliver over the measurement interval T. This data may appear in one or more frames possibly with inter-frame idle flags. Excess burst may be marked discard eligible (DE) by the network.

This field specifies a number of octets. Therefore the excess burst size is 8 x the contents of this field. If the excess burst size is symmetrical, octets 7c and 7d are not coded and the value in octets 7a and 7b are used for both directions.

NOTE: The same default values and range of values for the CIR, burst size,  excess burst size, committed measurement interval  and algorithms used for PVC should also be used in the case of SVC.

TABLE 10-20/X.76 (CONT.)

Link layer core parameters information element

Committed burst size magnitude (Octet  8 and 8a):
The Committed burst size magnitude field indicates the magnitude of the Committed burst size. It is expressed as a power of 10. It is multiplied by the Committed burst size value (octet group 6) to give the actual value of the Committed burst size. When the incoming committed burst size field is not included (in octet group 6), the incoming magnitude has no significance.

The outgoing and incoming Bc magnitudes are coded as a power of 10 as follows:

	bits
	3  2  1
	0  0  0		100
	0  0  1		101
	0  1  0		102
	0  1  1		103
	1  0  0		104
	1  0  1		105
	1  1  0		106
	All other values are reserved.

The values coded in octet 8a shall be the smallest values required to represent the outgoing and incoming committed burst sizes.

Excess burst size magnitude (Octet 9 and 9a):
The Excess burst size magnitude field indicates the magnitude of the Excess burst size. It is expressed as a power of 10. It is multiplied by the Excess burst size value (octet group 7) to give the actual value of the Excess burst size. When the incoming Excess burst size field is not included (in octet group 7), the incoming magnitude has no significance.

The outgoing and incoming Be magnitudes are coded as a power of 10 as follows:

	bits
	3  2  1
	0  0  0		100
	0  0  1		101
	0  1  0		102
	0  1  1		103
	1  0  0		104
	1  0  1		105
	1  1  0		106
	All other values are reserved.

The values coded in octet 9a shall be the smallest values required to represent the outgoing and incoming excess burst sizes.

10.5.19	Link layer protocol parameters
The purpose of the link layer protocol parameters information element is to indicate the requested layer 2 parameter values. The link layer protocol parameters information element is passed on transparently at the NNI.

FIGURE 10-22/X.76
 Link layer protocol parameters information element

10.5.20	Low layer compatibility
The purpose of the Low layer compatibility information element is to provide a means which should be used for compatibility checking by an addressed entity(e.g. remote DTE or an interworking unit or a high layer function of a DCE node addressed by the calling DTE). The Low layer compatibility information element is transferred transparently by a frame relay network between the calling DTE and the addressed entity.

FIGURE 10-23/X.76
Low layer compatibility information element

10.5.21	Packet layer binary parameters
The purpose of the packet layer binary parameters information element is to include the requested layer 3 parameter values. The support of this information element is a network option. This information element is supported by networks using Recommendation Q.933 at the UNI. If it is supported, the packet layer binary parameters information element is passed on transparently at the NNI.

FIGURE 10-24/X.76
Packet layer binary parameters information element

10.5.22	Progress indicator
The purpose of the progress indicator information element is to describe an event which has occurred during the life of a call. This information element may be carried twice in a message. The support of this information element is a network option. This information element is supported only by networks using Recommendation Q.933 at the UNI. If it is supported, the packet layer binary parameters information element is passed on transparently at the NNI.

FIGURE 10-25/X.76
Packet layer binary parameters information element

10.5.23	Restart indicator
The purpose of the restart indicator is to identify the class of the facility ( SVC or interface) to be restarted. Currently the use is only specified for single interface.

FIGURE 10-26/X.76
Restart indicator information element

TABLE 10-22/X.76 

Restart indicator information element   

Class (octet 3)

bits
3 2 1
1 1 0		Single interface (NOTE 1)
All other values are reserved.

NOTE 1 - All SVCs in the same interface as the signalling channel are to be restarted.

10.5.24	Reverse charging indication

The purpose of the reverse charging information element is to indicate that reverse charging has been requested for that call.  The use of this information elements is governed by bilateral agreements between the networks involved.

FIGURE 10-27/X.76
Reverse charging indicator information element

TABLE 10-23/X.76 

Reverse charging information element   

Reverse charging indication (octet 3)
Bits 
3 2 1 
0 0 1	Reverse charging requested
All other values are reserved

10.5.25	Transit Network Identification

The purpose of this information element is to identify a transit network along the path of call.

FIGURE 10-28/X.76
Transit Network Identification information element

TABLE 10-24/X.76

Transit Network Identification information element   

Network identification plan (octet 3)
bits
4 3 2 1 
0 0 1 0	Network identification using E.164 Country code (NOTE 1) 

0 0 1 1	Data network identification code (Recommendation X.121)
All other values are reserved.

NOTE 1 - This code point is used to identify public frame relay networks numbered under the E.164 numbering plan (See Appendix VI). The network identification consists of an E.164 Country Code followed by a network number. The maximum size is 8 octets.

Network identification (octet 4)
These characters coded according to Recommendation T.50 are organized according to the network identification plan specified in octet 3.

10.5.26	Transit network selection

The purpose of the Transit network selection information element is to identify a requested transit network. The transit network selection may be repeated in a message to select a sequence of transit networks through which a switched virtual circuit must pass. The support of this information element is a network option.. 

FIGURE 10-29/X.76

Transit network selection information element

TABLE 10-25/X.76

Transit network selection information element

Type of network identification  (octet 3)
	 bits
	7 6 5 
	0 1 1 		International network identification
	All other values are reserved.

Network identification plan (octet 3)
	 bits
	4 3 2 1 

	0 0 0 1	Carrier identification code/Network identification using 			E.164 Country code (NOTE 1) 
	0 0 1 1          Data network identification code (Recommendation X.121)   		
	All other values are reserved.

NOTE 1 - This code point is used to identify public frame relay networks numbered under the E.164 numbering plan (See Appendix VI). The network identification consists of an E.164 Country Code followed by a network number. The maximum size is 8 octets.

Network identification (octet 4)
These numeric characters are coded according to Recommendation T.50. They  are organized according to the network identification plan specified in octet 3.

10.5.27	User-user
The purpose of the user-user information element is to convey information between the users/DTEs. This information is carried transparently at the NNI. The user-user information element is coded as shown in Figure 10-30/X.76. 

FIGURE 10-30/X.76
User-to-user information element

10.5.28	X.213 priority
The purpose of this information element is to allow the optional negotiation of priority for the frame relay call in support of the OSI Connection-Mode Network Service (CONS). The support of this information element is a network option. This information element is supported by networks using Recommendation Q.933 at the UNI. If it is supported, the X.213 priority information element is passed on transparently at the NNI.

FIGURE 10-31/X.76
X.213 priority

10.6.1	Call establishment at the calling STE
10.6.1.1	Initiating a call setup request
The calling STE initiates the establishment of a SVC by transferring a SETUP message across the NNI on DLCI = 0. Following the transmission of the SETUP message, the calling STE shall start timer T303 and enter the call present state (NN6). If no response to the SETUP is received from the called STE before the first expiry of timer T303, the SETUP message shall be retransmitted and timer T303 restarted. At the second expiry, the calling STE shall perform clearing procedure in the backward direction with cause No 102 Recovery on timer expiry. 

Traffic parameters negotiation

The link layer core parameter: maximum frame information, throughput, committed and excess burst sizes selected by the calling STE shall be coded in the link layer core parameters information element and shall reflect any reduction performed by the calling STE while progressing the SVC setup request. 

Data link connection identifier selection
The calling STE shall select a DLCI to be included in the SETUP message  according to § 10.6.7. In the SETUP message, the data link connection identifier information element shall indicate an exclusive DLCI with no acceptable alternative. 

After sending the SETUP message to the called STE, the calling STE shall start timer T303 and enter the call present state (NN6). At the first expiry of timer T303, the calling STE shall resend the SETUP message. At the second expiry, the calling STE shall clear the call at the NNI by following the release procedure.

The calling STE shall include the calling party number information element in the SETUP message. Octet 3a shall be coded according to the information supplied by the DCE at the calling UNI or DTE/DCE interface.

10.6.1.2	Call proceeding 
At the receipt of a CALL PROCEEDING message, the calling STE node shall stop timer T303 and start timer T310. At the expiry of timer T310, the call shall be cleared with the called STE by following the procedure of § 10.6.3Normal release of a call  with cause No. 102 Recovery on timer expiryand shall initiate call clearing in the backward direction with cause No. 102 Recovery on timer expiry.

10.6.1.3	Alerting and call progressing
10.6.1.3.1 Handling of call alerting
At the receipt of an ALERTING message from the called STE, the calling STE shall pass this indication in the backward direction, start timer T301 and enter state NN7. At the expiry of this timer the call shall be cleared. 

When the ALERTING message is not supported by the calling STE, error handling procedures for message type or message sequence error defined in § 10.6.6 apply. 

10.6.1.3.2 Handling of call progressing
At the receipt of a PROGRESS message from the called STE, the calling STE shall pass this indication in the backward direction towards the calling DTE/DCE interface. When the PROGRESS message is not supported by the calling STE, error handling procedures for message type or message sequence error defined in § 10.6.6 apply. 

Any running timers may be canceled. It is a network option to implement a supervisory timer to limit the amount of time a SVC is in a predecessor state of the active state.  

10.6.1.4	Call established: Upon receiving a CONNECT message from the called STE indicating that the called user/DTE has accepted the call, the calling STE shall stop timer T310 or T301 (if running), perform the connect establishment process in the backward direction and enter the Active state (NN10).

10.6.2	Call establishment at the calling STE
10.6.2.1	Receiving a call set up request
Call establishment is performed by the called STE as a response to a call request received from an calling STE. The following procedures are followed by the called STE to setup the frame relay SVC.

At the receipt of a SETUP message, the called STE node shall enter the call initiated state (NN1). It shall then determine that the request to setup a frame relay SVC can be granted and that a route is available toward the called user. After examining the traffic parameters received from the calling STE node, the called STE node can take one of the following actions:

• If it is able to provide the requested traffic parameter values, it will progress the call to the called user with the original parameters received.

• If unable to provide the requested traffic parameters but able to provide at least the lowest acceptable parameters, it will progress the call to the called user after adjusting the appropriate parameters. The adjusted parameters will support at least the lowest acceptable values.

• If unable to provide at least the lowest acceptable traffic parameters, the calling STE will reject the call with cause No. 49 Quality of service not available and perform the clearing process in the backward direction towards the calling user/DTE. After that the called STE shall return to the null state (NN0).

If the called STE determines that it can set up the call, it shall reply with a CALL PROCEEDING to acknowledge the receipt of the SETUP message and to indicate that the call is being processed. After sending the CALL PROCEEDING message, the called STE node shall enter the Call proceeding sent state (NN3).

10.6.2.2	Alerting and call progressing

10.6.2.2.1 Handling of call alerting
If supported by the called STE, at At the receipt of an indication that the called user has been alerted, the called STE shall pass this indication to the calling STE by transferring an ALERTING message across the NNI, start timer T301 and enter state NN4. At the expiry of this timer the call shall be cleared.

10.6.2.2.2 Handling of call progressing
If supported by the called STE, at the receipt of a progress indication from the backward direction, the called STE shall send a PROGRESS message to the calling STE.  

Any running timers may be cancelled. It is a network option to implement a supervisory timer to limit the amount of time a SVC is in a predecessor state of the active state.  

10.6.2.3	Call established 
Upon receiving an indication that the called user accepted the call, the called STE node send a CONNECT message to the calling STE node and enter the Active state (NN10). The link layer core parameters information element contains the final negotiated values.

If the Connected number information element is present in the CONNECT message, then octet 3a of the Connected number information element shall be coded according to the information supplied by the network at the called UNI or DTE/DCE interface.

10.6.3	Normal call clearing 
Normal clearing is usually initiated at a UNI. At the NNI, call clearing may be initiated by either side of the NNI as a response to a call clearing request initiated at a UNI or for other reasons.

10.6.3.1	Initiation of the clearing of a call
To clear a call at the NNI, a network shall transfer a RELEASE message, start timer T308, release the DLCI and enter the Release request state (NN11). 

At the receipt of a RELEASE COMPLETE message as a response to the RELEASE message, the receiving network shall stop timer T308, release the call reference for future use and enter the Null state (NN0).

NOTE - The RELEASE COMPLETE message has only local significance and does not imply an acknowledgment of end-to-end clearing.

If timer T308 expires for the first time, the STE shall retransmit the RELEASE message with a cause number originally contained in the first RELEASE message; restart timer T308 and remain in the release request state (NN11). In addition, the STE may indicate a second Cause information element with cause No. 102, recovery on timer expiry. if no RELEASE COMPLETE message is received from the other STE before timer T308 expires a second time, the STE shall: release the call reference and return to the Null state (NN0). This event may be logged as an abnormal event, the actions taken are network dependent.

10.6.3.2	Receipt of a RELEASE message

At the receipt of the RELEASE message, the receiving STE shall enter the Release indication state (NN12). This message then prompts the receiving STE to release the DLCI and to initiate procedures for clearing the SVC towards the DTE. Then the receiving STE shall send a RELEASE COMPLETE message to the initiating STE, free the call reference and return to the Null state (NN0).

10.6.3.3	Clearing in the null state
In the null state (NN0) a network shall perform the clearing procedure by a sending RELEASE COMPLETE message, release any allocated resource and remain in the null state (NN0).

10.6.3.4	Clearing collision
A call clearing collision happens when the two sides of the NNI simultaneously send each other a RELEASE message with the same call reference identifier.

When a network detects a clearing collision, it shall consider the receipt of the RELEASE message a reply to the RELEASE message sent previously. It shall therefore release the call reference for future use and enter the Null state (NN0).

10.6.4	 Restart procedure
The restart procedure is used to return a frame relay NNI to a idle or null state. The restart procedure is used to recover from internal failure, after power-up or after internal re-initialization. The restart procedure affects only the switched virtual circuits and has no effect on the permanent virtual circuit. A result of the execution of the restart procedure, the switched virtual circuits will be cleared and will return to the null state.

10.6.4.1	 Sending a RESTART message
A RESTART message is sent by a network across the NNI in order to return the whole interface to the Null or idle state. Upon transmitting the RESTART message the sender enters the Restart Request state, starts timer T316 and waits for the a RESTART ACKNOWLEDGE message. Also, no further RESTART messages shall be sent until a RESTART ACKNOWLEDGE message is received or timer T316 expires. Receipt of a RESTART ACKNOWLEDGE message stops timer T316, frees the DLCI and call reference values for reuse.

If a RESTART ACKNOWLEDGE message is not received prior to the expiry of timer T316 one or more subsequent RESTART messages may be sent until a RESTART ACKNOWLEDGE message is returned. Meanwhile, no calls shall be place or accepted over the interface. The number of unsuccessful restart attempts is limited to a default value of two. When this limit is reached the originator of the restart attempt shall consider the restart procedure successfully completed and the DTE/DCE interface is available for new calls.

The RESTART and RESTART ACKNOWLEDGE messages shall contain the global call reference value. The call reference flag of the global call reference applies to restart procedures. In the case where both sides of the NNI initiate simultaneously restart requests, the receipt of a RESTART message shall be considered a reply to the RESTART message transmitted and no RESTART ACKNOWLEDGE shall be sent or expected.

10.6.4.2	 Receipt of a RESTART message
Upon receiving a RESTART message the recipient shall enter the Restart state associated to the global call reference and start timer T317; it shall then initiate the appropriate internal actions to clear all calls on the interface and to return the interface to the idle state. Upon completion of internal clearing, timer T317 shall be stopped and a RESTART ACKNOWLEDGE message transmitted to the originator, and the Null state entered. if timer T317 expires prior to completion of internal clearing an indication shall be sent to the maintenance entity.

Even if all call references are in the Null state and all data link connections are in the idle condition, the receiving entity shall transmit a RESTART ACKNOWLEDGE message to the originator upon receiving a RESTART message.  

10.6.5	Status enquiry and status procedures

10.6.5.1	 Status enquiry procedure
Whenever a network wishes to check the correctness of a call state at the other network, a STATUS ENQUIRY message may be sent. Upon sending the STATUS ENQUIRY message, timer T322 shall be started in anticipation of receiving a STATUS message. While timer T322 is running, only one outstanding request for call state information shall exist per call reference. If switched virtual circuit clearing is received while timer T322 is running, it shall be stopped and clearing shall continue.

Upon receipt of a STATUS ENQUIRY message, the receiver shall respond with a STATUS message, reporting the current call state and cause No. 30  Response to STATUS ENQUIRY. Sending or receiving a STATUS message does not result in a state change.

The side having received the STATUS message shall inspect the cause information element. If it is not No. 30 Response to STATUS ENQUIRY, timer T322 shall continue to time for an explicit response to the STATUS ENQUIRY message. If a STATUS message is received with the cause No. 30,  timer T322 shall be stopped and the appropriate action taken based on the information in that STATUS message about the call state of the sender and the current call state of the receiver.

If timer T322 expires and a STATUS  was received with another cause value than No. 30, appropriate actions based on the cause received and the call state of the sender shall be taken.

If timer T322 expires and no STATUS was received,  the STATUS ENQUIRY message may be retransmitted one or more times until a response is received. The number of times a STATUS ENQUIRY is retransmitted is an implementation dependent value.

The switched virtual circuit shall be cleared with cause No. 41  Temporary failure, if the STATUS ENQUIRY message is retransmitted the maximum number of times.

10.6.5.2	Receiving a STATUS message
On receipt of a STATUS message reporting an incompatible state, the receiving entity shall:

• Clear the call by sending the appropriate clearing message with cause No. 101 Message not compatible with call state; or,

• Take other actions which attempt to recover from a mismatch and which are an implementation option.

Except for the following rules, the determination of which state are incompatible is left as an implementation decision:

• If the receiver is in the Null state and the STATUS message indicates the Null state, then no action shall be taken by the receiver other than discarding the message an staying in the Null state.

• If the receiver is in any state except the Null state and the STATUS message indicates the Null state then the receiver shall release all resources, the DLCI and the call reference and move to the Null state.

• If the receiver is in the Release request state (NN19) and the STATUS message indicates any state except the Null state then no action shall be taken. 

• if the receiver is in the Null state and the STATUS message indicates any state except the Null state then the receiver shall either send:

- A RELEASE message with cause No. 101 Message not compatible with call state and then follow the normal clearing procedure; or, 

A RELEASE COMPLETE message with cause No. 101 Message not compatible with call state and remain in the Null State.

If a STATUS message is received in a compatible state but contains one of the following causes:

• No. 96  Mandatory information element missing
• No. 97  Message type non-existent or not implemented
• No. 99  Information element non-existent or not implemented
• No. 100  Invalid information element contents

The actions to be taken are an implementation option. If no other procedure are defined, the receiver shall clear the call with the appropriate procedure defined in Section 4.4.3 using the cause value specified in the received STATUS message.

10.6.5.3	Receipt of the STATUS message with the global call reference

On receipt of a STATUS message with the Global call reference, no action shall be taken on the STATUS message. On receipt of another message with the Global call reference than the STATUS message, a STATUS message with cause No. 81 invalid call reference values is returned; the call reference information element is coded with  the global call reference and the call state is coded as REST0.

10.6.6	 Handling of error conditions 
Detailed error handling procedures are implementation dependent. This section provides general rules facilitating the orderly treatment of error conditions required by each  implementation to support. These general rules do not take precedence over applicable procedures as specified in other sections of this Recommendation. The order of precedence of these rules is defined by the order of description in this section.

Protocol discriminator error:
When a message is received with a protocol discriminator coded other than Q.931 user-network call control message  '00001000', the message shall be ignored (discarded) and no further action will be taken.

Message too short:
When a message is received that is too short to contain a complete message type information element, that message shall be ignored.

Invalid call reference format:
a) If the call reference information element octet 1, bits 5-8 do not equal 0000, then the message shall be ignored.

b) If the call reference information element octet 1, bits 1-4 indicate a length greater than the maximum length supported by the receiving equipment, then the message shall be ignored.

c) When a message is received with a dummy call reference it shall be ignored.

Call reference procedural errors:

a) Whenever a message (CALL PROCEEDING, CONNECT or RELEASE) except SETUP, RELEASE COMPLETE, STATUS OR STATUS ENQUIRY is received specifying a call reference which it does not recognize as related to an active call or a call in progress, normal call clearing is initiated by sending a RELEASE COMPLETE message with cause No. 81  Invalid call reference value  and remains in the Null state (NN0).

b) When a RELEASE COMPLETE is received that specifies a call reference which it does not recognize as related to an active call or a call in progress, no action should be taken.

c) When a SETUP message is received that specifies a call reference which is recognized as related to an active call or a call in progress or with a call reference flag incorrectly set to '1', that message shall be ignored.

d) When any message except RESTART, RESTART ACKNOWLEDGE or STATUS is received using the global call reference, no action should be taken on this message and a STATUS message using the global call reference with cause No. 81 Invalid call reference value  and a call state indicating REST0 shall be returned.

e) When a Status message is received, the procedures of  section 10.6.5.2  apply.

f) When a STATUS INQUIRY message is received that specifies a call reference which is not recognized as related to an active call or a call in progress, the procedures of § 10.5.5.1 shall apply.

Message type or message sequence errors:

• Whenever an unexpected RELEASE COMPLETE message is received, the receiving STE shall stop all timers, release the DLCI and the call reference and return to the Null state (NN0).

• Whenever an unexpected message, except RELEASE, RELEASE COMPLETE, or an unrecognized message (including ALERTING and PROGRESS messages) is received in any state other than the Null state, a STATUS message shall be returned with cause No. 98  Message not compatible with call state or message type non-existent or not implemented and the corresponding diagnostic.  

   Instead of cause No. 98, the following cause values may be returned depending on the message received (unrecognized/ not implemented or unexpected in the current state):
a) Cause No. 97 Message type non-existent or not implemented; or,
b) Cause No. 101 Message not compatible with call state.

   Alternatively instead of sending a STATUS message, a STATUS INQUIRY message may be sent requesting the call state of the sender. This alternative is not applicable to messages using the global call reference.

   No state change shall be made after sending either the STATUS or STATUS INQUIRY message.

Information element out of sequence:
A variable length information element which has a code value lower than the code value of the variable length information element preceding it shall be considered as out of sequence information element.

   If the network or the user receives a message containing an out of sequence information element, it may ignore this information element and continue to process the message. If the network or the user chooses to ignore this out of sequence information element, then the error handling procedure for missing mandatory information elements as described below shall apply. If the out of sequence information element is non-mandatory, the receiver continues to process the message.

NOTE - Some implementations may choose to process all the information elements received in a message regardless of the order in which they are placed.

Duplicated information elements:
• If an information element is repeated in a message in which repetition of the information element is not permitted, only the contents of the first instance of the information element shall be considered and all subsequent instances shall be ignored.

• When repetition of an information element is permitted and if the limit of repetition of the information element is exceeded, the contents of the instances of the information element appearing up to the limit of repetition shall be handled and all subsequent repetitions of the information element shall be ignored.

Mandatory information element missing:
• When a RELEASE COMPLETE message is received with the cause information element missing, it will be assumed that cause No. 31  Normal, unspecified was received.

• When a RELEASE message is received with the cause information element missing, it will be assumed that cause No. 31  Normal, unspecified was received. However the reply, RELEASE COMPLETE, shall be sent to the other side of the NNI with the cause value No. 96,  Mandatory information element is missing.

• When a SETUP or RELEASE message is received which has one or more mandatory information element missing, the receiving STE shall clear the SVC by following the clearing procedures as described in § 10.5.3.1 with cause No. 96  Mandatory information element is missing shall be returned.

• When a message other than SETUP, RELEASE or RELEASE COMPLETE  is received which has one or more mandatory information elements missing, no action should be taken on the message and no state change should occur. A STATUS message shall be returned with cause No. 96 Mandatory information element is missing. 

Mandatory information element content error:

•  Information elements with a length exceeding the maximum standardized length may either be treated as an information element with content error, or the receiver may ignore the octets detected as additional, and process the remaining contents of the information element.

• When a RELEASE COMPLETE message is received with an invalid content of the cause information element, it will be assumed that cause No. 31  Normal, unspecified was received.

• When a RELEASE message is received with an invalid content of the cause information element, it will be assumed that cause No. 31  Normal, unspecified was received. However the reply, RELEASE COMPLETE, shall be sent to the other side of the NNI with the cause value No. 100  Invalid information element contents. 

• When a SETUP message is received which has one or more mandatory information element with an invalid content, the receiving entity shall clear the SVC by following the clearing procedures as described in § 10.5.3.1 with cause value No. 100  Invalid information element contents  shall be returned.

• When a message other than SETUP,  RELEASE or RELEASE COMPLETE  is received which has one or more mandatory information elements with an invalid content, no action should be taken on the message and no state change should occur. A STATUS message with cause No. 100 Invalid information element contents  shall be returned.

Unrecognized information element:
• When a RELEASE COMPLETE message is received which has one or more unrecognized information elements, no action shall be taken on the unrecognized information elements.

• When a RELEASE message is received which has one or more unrecognized information element, a RELEASE COMPLETE message is returned with cause No. 99  Information element non-existent or not implemented, the diagnostic field, if present shall contain the information element identifier for each information element which was unrecognized. 

• When a message is received which has one or more unrecognized information elements action shall be taken on the message and those information elements which have a valid content. When the received message is other than a RELEASE or RELEASE COMPLETE message, a  STATUS message may be returned indicating the call state of the sender before taking action on the valid information elements of the message. The cause information element shall contain cause No. 99  Information element non-existent or not implemented, and the diagnostic field, if present shall contain the information element identifier for each information element which was unrecognized. Subsequent actions are determined by the sender of the faulty message.

NOTE: The diagnostic of cause No. 99 facilitates the decision in selecting an appropriate recovery procedure at the reception of a STATUS message. Therefore, it is recommended to provide cause No. 99 with diagnostic information.

Non-mandatory information element content error:
When a message is received which has one or more non-mandatory information elements with invalid content, action shall be taken on the message and those information elements which have a valid content. A STATUS message may be returned indicating the call state of the sender before taking action on the valid information elements of the message. The cause information element shall contain cause No. 100  Invalid information element contents shall be returned and the diagnostic field, if present shall contain the information element identifier for each information element which has content error. Subsequent actions are determined by the sender of the faulty message.

Unexpected recognized information element:
When a message is received with a recognized information element not defined to be contained in that message, the receiving entity shall treat the information element as an unrecognized information element and follow the procedures for handling non-mandatory unrecognized information elements.

Data link reset:
Whenever a signaling entity is informed of a data link reset,  no special actions shall be taken, the appropriate procedures  (normal procedures or error handling procedures) described above shall be performed.

Data link failure:

 Any SVC shall be cleared.

10.6.7	DLCI management
10.6.7.1	DLCI allocation between SVCs and PVCs
The range of usable DLCIs is partitioned into two subranges: one for PVC and the other for SVC.  By bilateral agreement between networks, it shall be determined which range of DLCIs will be allocated to PVCs. The remaining DLCIs are available for SVC.

10.6.7.2	 DLCI collision at the NNI
By bilateral agreement one network will select DLCI starting from the highest end of unused DLCI value and the other from the lowest end. When both networks select the same DLCI value, a DLCI collision occurs. To resolve a DLCI collision both networks will clear the call using cause No. 6 Channel unacceptable. or cause No. 44 requested circuit/channel not available. 

10.6.8	List of timers at the NNI

The following mandatory timers are used at the FR NNI: T301, T303, T308, T310, T316, T317, T322.

TABLE 10-25/X.76 

Timers 

Timer No.	Default value	Cause for start	Normal stop	 1st expiry	2nd expiry	
T301	Min 3 min.	ALERT  received	CONN received	Clear call	Not restarted	
T303	4 s 	SETUP sent	CALL PROCEEDING, CONNECT or clearing message received 	Retransmit SETUP. restart T303 unless a clearing message was received 	Not restarted. Clear call	
T308	4 s	REL sent	Clearing message received	Retransmit RELEASE. Restart T308	Not restarted. Release call reference	
T310	30-40 s	CALL PROC received 	CONNECT or clearing message received 	Clear call	Not restarted	
T316	120 s	RESTART sent	RESTART ACK received	RESTART may  several times	be transmitted	
T317	Implementation Dependant	RESTART  received	Internal clearing of call references	Maintenance Timer is not 	notification. restarted.	
T322	4 s	STAT ENQ sent	STATUS or a clearing message received.	STATUS ENQUIRY retransmitted	May be transmitted several times	

10.6.9	Frame relay NNI Facilities 

Categorization of the support for Frame Relay NNI facilities is as follows:-It is mandatory to support the following frame relay network facilities:

• Transit network identification (mandatory  for originating, terminating and transit networks)
•  Call identification (mandatory)
•  Closed user group interlock code (mandatory )
•  Reverse charging indication (optional)
•  Clearing network identification (mandatory)
•  Transit network selection (optional)
•  Frame transfer priority (for further study)

10.6.9.1	Transit Network Identification

Transit Network Identification is used to identify a Transit Network traversed by a frame relay SVC. It is used to record the path taken by the SVC for inter-network Accounting, Operations and Routing control purposes. It is mandatory for all networks to support this facility.Only networks operating as Transit Networks are required to add their Transit Network Identification in a SETUP message.  Networks may record and check the Transit Network Identification codes present in any message.   

The Transit Network Identification is a unique network identification code allocated to the network (see Appendix VI). Networks may choose to request the allocation of  a network  identification which is either a Recommendation X.121 DNIC, or is derived from a Recommendation E.164 Country Code (see Appendix VI). The same network identification code applies to Clearing Network identification (see 10.6.9.5).

Transit Network Identification information in the CONNECT message is used to record the inter-network path taken by each call for Inter-network Accounting, Routing and Fault Diagnosis purposes.Transit Network Identification information in either or both SETUP and CONNECT messages is used to prevent inter-network routing loops and to check that such routing loops are not created.

Each Transit Network shall include its Transit Network   Identification information element in the SETUP message. When the SVC being established traverses multiple Transit Networks, there will be multiple Transit Network Identification information elements in the SETUP message. The order of inclusion of Transit Network Identification information elements in the SETUP message corresponds to the order of traversal of transit networks by the SVC being established in the forward direction.

A Transit Network Identification information element is present for each transit network in the CONNECT message returned in the backward direction. It is mandatory for the terminating network to  ensure that all Transit Network Identification elements received in the SETUP message, are included in the responding CONNECT message. The order of Transit Network Identification information elements in the CONNECT message is the same as the order of traversal of transit networks by the SVC being established in the forward direction. 

Transit networks shall pass Transit Network Identification information elements in the CONNECT message unchanged and in the same order in which they were received. Transit networks may check and record the Transit Network Identification information elements. If a transit network checks the transit network information elements in the CONNECT message and determines that it’s own Transit Network Identification information element is not present, the call shall be cleared with cause #96 Mandatory Information Element missing. The diagnostic shall include the Transit Network Identification information element identifier.

The originating  network shall accept and may check and record the received Transit Network Identification elements in the CONNECT message. 

Transit Network Identification  information elements may also be present in the first clearing message (RELEASE or RELEASE COMPLETE) only if the RELEASE or RELEASE COMPLETE message is in direct response to a SETUP message. If present, the order of Transit Network Identification information elements is the same as the order of transit networks up to the point at which the first clearing message was sent.

The presence of a duplicate Transit Network Identification Information element  parameter in any message may be treated as an error and tin this case the call shall be cleared with a Cause to be decided at th March 97 SG7 meeting. The Diagnostic will contain the duplicate Transit Network Identification information element.

The maximum number of transit networks involved in a call is limited to six. As a result all networks will treat the presence of more than six Transit Network Identification information elements as an error. If  the maximum number of Network identification identification information elements is reached, the transit network not able to add its Transit Network Identification, will clear the call in the backward direction with Cause #3 No Route to Destination and Diagnostic containing the Transit Network Identification information element code. If the maximum number of Transit Network Identification information elements exceeds  6 in any message, the call shall be cleared with Cause #111 Protocol Error Unspecified and Diagnostic containing the Transit Network Identification information element identifier. 

10.6.9.2	Call  Identification

Call Identification provides a method to uniquely identify each inter-network call. All networks involved in a call may record the Call Identification information element in the SETUP message so that it can be used for inter-network accounting and problem investigation/operations purposes. 

Call Identification is an information element which is always present in the SETUP message. The Call Identification information element is passed unchanged from the originating network to the terminating network. The Call Identification value is established by each originating network and is used as a unique identifying information for each inter-network call. The Call Identification parameter shall be a unique value for an extended period of time, for instance, corresponding to the accounting period of the network.
The coding of the Call Identification is a fixe length 4 octets of binary coded data. The contents of the Call Identification information element is determined by the originating network and is not specified in this Recommendation. 

10.6.9.3	Closed User Group interlock code

The Closed User Group interlock code is a facility  used for enabling the establishment of virtual calls by DTEs which are members of inter-network Closed User Groups.

When the Closed User Group interlock code information element is present in the SETUP message, it indicates that the inter-network call is requested on the basis of  a valid inter-network Closed User Group membership. The network of the calling DTE supplies the relevant inter-network Closed User Group interlock code in the SETUP message. It may also signal an associated outgoing access capability.

The Closed User Group interlock code information element is passed unchanged by any transit network to the terminating network in the SETUP  message. The terminating network is responsible for determining whether the call is presented to the called DTE based on the contents of the Closed User Group interlock code information element.

Administrative arrangements for Closed User Group Interlock Codes are according to Recommendation X.180.

10.6.9.4	Reverse Charging Indication 

Reverse Charging Indication is an optional facility  used for enabling inter-network calls to be established for which Reverese Charging applies. Its use between networks is subject to a bilateral agreement between the originating network and the adjacent network, which may be a  Transit Network or the terminating network. 

If a network receives a Reverse Charging Indication information element and does not support this service or has no bilateral agreement with the adjacent network sending this information element, it shall clear the call with cause No, 69 Requested facility not Implemented, and shall not use the error procedures applicable to  optional information elements. The Diagnostic will indicate the Reverse Charging information element identifier.

The Reverse Charging Indication information element is only present in the call SETUP message when Reverse Charging is requested by the calling user to apply to the call.

The Reverse Charging indication information element is passed  unchanged by any transit network to the terminating network in the SETUP message.

10.6.9.5	 Clearing Network Identification 

Clearing Network Identification  is a facility used to identify the network responsible for requesting the release of a SVC. The Clearing Network  identification may be recorded by networks and used for inter-network operations and fault management. It is mandatory for all networks to include this information when clearing a call and to accept this information when received from another network. Transit networks shall pass the Clearing Network Identification information element unchanged.

The Clearing Network Identification is a unique identification code allocated to the network (see 10.6.9.1 and Appendix VI). Networks may choose to request the allocation of  a network  identification which is either a Recommendation X.121 DNIC, or is derived from a Recommendation E.164 Country Code (see Apppendix VI). The same network identification code applies to Transit  Network identification (see 10.6.9.1).

The Clearing Network identification information element is included in the first clearing message (RELEASE or RELEASE COMPLETE) only when the network initiates the release of a SVC. When the Clearing Network is a transit network, the Clearing Network Identification information element will be present in the first clearing message sent in each direction.

Clearing Network Identification is not present when a DTE or Private Network initiates the clearing of a call.

NOTE - In the case where two or more networks clear a call simultaneously, each clearing network will include it’s own  Clearing Network Identification in the first clearing message. In this case a received Clearing Network Identification may not have end-to-end significance across all of the networks involved in the call.

10.6.9.6	 Transit network selection

Transit Network Selection is an optional facility used for selection of transit networks according to the request of the calling DTE. The  use of transit network selection  is subject to bilateral agreements between the networks. 

NOTE - The rationale for including multiple transit network selection in Recommendation X.76 results from the use of multiple transit network selection in Recommendation Q.933 at the UNI and is also included for future use in other Recommendations. Recommendation Q.933 permits the selection of up to four transit networks at the UNI, resulting  in a maximum number of three repeated Transit Network Selection information elements in a SETUP message at the NNI. 

The order of Transit Network Selection information elements in the SETUP message is identical to the order specified by the calling DTE. 

A network receiving a SETUP message containing Transit Network Selection information elements will route the call directly to the first network as identified by the first transit network selection information element and will remove this information element before sending the SETUP message to that network. If it is not possible to route directly to the requested network, or if a network does not recognize a specified transit network, the call shall be cleared with Cause #2 No Route to Specified Transit Network. The diagnostic  shall contain a copy of the contents of the Transit network selection information element in question. 

A network may screen all remaining Transit Network Selection information elements to:-

(a) Avoid routing loops

(b) Ensure an appropriate inter-network relationship exists between selected network

(c) Ensure compliance with national and local regulations

If the Transit Network Selection is of an incorrect format or fails to meet criteria (a), (b) or (c), the network shall clear the call with Cause #91 Invalid Transit Network Selection. The diagnostic shall contain a copy of the contents of the Transit network selection information element in question.

If the maximum number of Transit Network Selection information elements in a SETUP message exceeds  3, the call shall be cleared with Cause #111 Protocol Error Unspecified and Diagnostic containing the Transit Network Selection information element identifier. 

10.6.9.7	Frame transfer priority facility

The Frame transfer priority facility is for urgent further study. 

NOTE - An information element identifier has been reserved in the digital Subscriber Signalling System No. 1 (DSS 1) set of identifiers for variable length information elements to signal a requested priority level at the NNI.
This information element is known as "Frame transfer priority information element" and the reserved identifier (to be coded in the first octet) is 0110 1010.

Annex A
Signalling for switched PVC (SPVC)
(This annex forms an integral part of this Recommendation)

This annex describes optional procedures which provide a means of establishing a PVC using PVC segments at the UNIs and SVCs at the NNIs.  This mapping is provided by establishment of a switched connection between two endpoints that support PVCs.  This connection is referred to as a switched PVC (SPVC).  The SPVC appears to the DTE as a PVC, but is connected through multiple networks as a SVC.  The SVC is utilized to achieve a high degree of resiliency between networks along with a reduction in provisioning requirements at the NNI.  
The endpoints of an SPVC provide the mapping between the PVCs at the network edges and the SVCs that transit the networks.  The mechanisms for achieving this mapping are internal to the networks.  Each endpoint of the SPVC will service the PVC signalling on its respective UNI and will logically act as a proxy DTE for purposes of the network’s signalling.  These endpoints, the first network nodes encountered after the UNI, are configured by the network management entity (e.g., loading of parameters such as CIR, Bc, Be, called address).Figure A-1/X.76 provides a reference model.

FIGURE A-1/X.76
SPVC Reference configuration

Endpoints of the SPVC have the ability to setup the SPVC.  The endpoint sending the SETUP message is referred to as the calling endpoint.  The endpoint that receives a SPVC connection request is referred to as the called endpoint.
The PVC UNIs serviced by the endpoints are identified by unique frame relay addresses (e.g., E.164 and X.121) which are assigned by the network management entity.  The address of the origin PVC UNI is encoded in the Calling party number information element of the SETUP message that establishes the SPVC.  The address of the destination PVC UNI is encoded in the Called party number information element of the SETUP message that establishes the SPVC.
The calling endpoint selects the Data Link Connection at the destination PVC UNI with the Called party SPVC information element.  A Data Link Connection can be selected for:
a)	A specific DLCI value at the called endpoint's PVC UNI;
b)	A logical Data Link Connection at the called endpoint's PVC UNI;
c)	Any available DLCI at the called endpoint's PVC UNI.
A logical Data Link Connection is mapped to a specific DLCI by the called endpoint following receipt of a setup request.  The logical Data Link Connection is indicated when the Called party SPVC IE is encoded using a Called endpoint selection type of "Specific SPVC Correlator".  Both endpoints must be provisioned to support the same Specific SPVC correlator.  Support of the Specific SPVC correlator is optional.
NNI facilities applicable to SVCs are also applicable at the NNI when the endpoints are SPVCs. These NNI facilities are, Transit Network Identification, Call  Identification and Clearing Network Identification. Facilities that may be configurable to be used at the SPVC endpoint are, Reverse Charging and Transit Network Selection. Closed User Group indication is not applicable to SPVC endpoints.
The SPVC procedures include:
a)	SPVC establishment;
b)	interworking with the PVC procedures of X.36. (Note 1)
Note 1:  These procedures also apply to the PVC procedures of Annex A of Q.933.

A.1  Messages needed for SPVC Establishment
The following information elements are used to carry end-to-end information in the SETUP and CONNECT messages:  Called party SPVC  information elelment, and Link layter core parameters.  The User - user information is required when supporting the Specific SPVC Correlator. The SETUP and CONNECT messages used to establish an SPVC shall contain the Called party SPVC information element.

A.2  Called party SPVC information element
The purpose of the Called party SPVC information element is to identify the DLCI used for a PVC at the destination UNI.  The Called party SPVC information element specifies either a specific DLCI, a Specifc SPVC correlator, or any available DLCI at the destination may be used.  The length of this information element is variable.  See Figure A-2/X.76.
Although the Called party SPVC information element is included in the SETUP and CONNECT messages at the NNI during SPVC establishment, this information element is not processed at the NNI.  The NNI ensures that the Called party SPVC information element is forwarded to the adjacent network where it is processed by the called and calling endpoints.

        8     7     6     5     4     3     2     1    Octet
     +-----+-----------------------------------------+
     |     |         Called party SPVC               |
     |  0  |  0     0     0     1     0     1     0  |   1   (Note 1)
     |     |       information element               |
     +-----+-----------------------------------------+
     |      Length of Called party SPVC contents     |   2
     +-----+-----------------+------+----------------+
     |  1  |      Spare      | NEW  |Called endpoint |   3
     | ext |                 | 0 ffs|selection type  |
     +-----+-----------------+------+----------------+
     |  0  |  0  |  Data link connection identifier  |   4* (Note 2)
     | ext |spare|     (Most significant 6 bits)     | 
     +-----+-----+-----------------+-----------------+
     | 0/1 |Data link conn identif |      Spare      |   4a*
     | ext |(2nd most sig 4 bits)  |                 |
     +-----+-----------------------+-----------+-----+
     |  1  | Data link connection identifier   |  0  |   4b*
     | ext | (3rd most significant 6 bits)     |(res)| 
     +-----+-----------------------------------+-----+
     |  0  | Data link connection identifier         |   4b*
     | ext | (3rd most significant 7 bits)           | 
     +-----+-----------------------------------+-----+
     |  1  | Data link connection identifier   |  0  |   4c*
     | ext | (4th most significant 6 bits)     |(res)| 
     +-----+-----------------------------------+-----+
Note 1 - The information element is encoded as “comprehension required” 
Note 2 - This octet group is included when the called endpoint selection type indicates Specific DLCI or Assigned DLCI.
FIGURE A-2/X.76
Called party SPVC information element

TABLE A-1/X.76 

Called party SPVC information element   

Called endpoint selection type (octet 3)	
	
      Bits |         Meaning	
      3 2 1|	
      -----+---------------------	
      0 0 1| Any DLCI (Note 1)	
      0 1 0| Specific DLCI	
      0 1 1| Assigned DLCI	
      1 0 0| Specific SPVC Correlator (Note 2)	

Note 1 - When the "Any DLCI" code point is used, it is assumed that the user equipment supports peer discovery at the protocol layers above the frame relay layer.

Note 2 -  Support of this is optional and must be bilaterally agreed between the two endpoints.

New bit (octet 3) For further study.
This bit is reserved for future use as a "new bit" indication. It is set to zero on transmission and should not be interpreted on receiption.

Data Link Connection Identifier (octet 4-4c)	
See section 4.5.15 of X.36 (Data link connection identifier)
	
A.3  SPVC Procedures
The procedures of this Annex utilize the basic SVC connection control procedures for frame relay.  Additional procedures are described below.

A.3.1  Initiating SPVC establishment
The SPVC endpoint may intiate SPVC establishment when all of the following conditions are met at the endpoint:
a)	the PVC UNI data link layer is operational;
b)	the PVC UNI LIV procedures detect no service affecting condition;
c)	the PVC UNI includes the DLC information element in a full status response with the Active bit asserted (Note:  This condition applies when the PVC UNI operates the user-to-network interface bidirectional procedures).
SPVCs provisioned to request connection to a specific DLCI or a correlated connection can attempt SPVC establishment from either one or both endpoints.
SPVCs provisioned to request connection to any DLCI must attempt SPVC establishment from a single endpoint chosen through bilaterial agreement.
The Called party SPVC information element is included in the SETUP message.  The Called party number information element shall contain the address of the called endpoint and the Calling party number information element shall contain the address of the calling endpoint.
When the SETUP message is sent across the X.76 interface, it contains the calling party number with the screening indicator code point set to either Network Provided, Verified, Passed, or User Provided, Verified, Passed.

A.3.2  Receiving a SETUP message at the called endpoints 
When a SETUPmessage is received at the called endpoint, the called endpoint must screen the received SETUP message for the Called party SPVC IE.  If the Called party SPVC information element is present, the SETUP is for an SPVC. When a Called party SPVC information element is present in the SETUP message, the called endpoint shall validate the incoming setup request as described below and in the following subclauses. The called endpoint shall verify also the calling party number to determine if the calling party is authorize to establish the SPVC.

A.3.2.1  Call collision
Call setup collisions are detected for SPVCs provisioned to initiate connections to specific or correlated DLCIs.  A collision is detected when an incoming setup request identifies a specific or correlated Data Link Connection on a remote endpoint for which a setup has already been sent.
In the event of call setup collision, the incoming call is cleared with cause No 34 Channel/circuit unavailable. The calling endpoint should re-attempt to establish the SPVC after an amount of time randomly determined to avoid consecutive call collisions. The maximum number of re-attempts is a local matter.

A.3.2.2 Confirmation of SPVC to configured peer
If the Called party SPVC IE indicates “Specific DLCI” or "Specific SPVC correlator”, the Calling Party Number IE in the SETUP message shall be examined by the called endpoint.  If the Called party SPVC IE indicates “Any DLCI”, the  Calling party number may optionally be examined by the called endpoint.  If the calling endpoint identified in the Calling party number information element in the SETUP message is not authorized by the called endpoint, the call shall be cleared with cause #21, "call rejected".  In addition, if the Called party SPVC IE indicates “Specific DLCI” or "Specific SPVC correlator”, the called endpoint shall verify that the calling number is authorized to connect to the requested DLCI at the called end.

A.3.2.3 Allocation of DLCI at called PVC UNI
In the SETUP message, the Called party SPVC information element indicates one of the following for the PVC:
a)	any DLCI,
b)	specific DLCI.
c)	specific SPVC Correlator
In case a), an unused DLCI will be selected by the called endpoint for use on the PVC UNI.  A call will be cleared with cause No. 21 Call rejected, when the called endpoint is not able to connect the call.
In case b), the requested DLCI is checked against the available DLCI values at the called endpoint.  If the DLCI is not available for use, the call shall be cleared with cause No. 21, Call rejected.
Some reasons why the called DLCI may not be available are:  
•	The DLCI is in use, 
•	The Calling party does not have authorization to use the DLCI.

In case c), the DLCI is not included in the Called party SPVC information element. In the event the called party does not support the Specific SPVC correlator option, the call will be cleared with cause No. 21 Call rejected.  When supported, the SETUP message will include the User-user information elelment which will contain octets bilaterally agreed between the two endpoints.  The value of the octets are used at each endpoint to determine which DLCI to use at the local PVC interface.  These octets are referred to as the SPVC Correlator.  It is required that both endpoints use the same bilatterally agreed value to identify the SPVC when sending a SETUP message.
The DLCI used at the called endpoint is indicated in the Called party SPVC IE of the CONNECT message.  The Called endpoint selection type will indicate Assigned DLCI and the Data link connection identifier will contain the selected DLCI value.  

A.3.2.4  Called endpoint availability
If the called endpoint is not available due to an outage or other error condition, the call shall be cleared with cause No. 27, Destination out of order.  Some reasons why an outage may occur at the called endpoint include:
•	The called endpoint operating the procedures of X.36 receives a status message indicating the DLCI is inactive or not provisioned.
•	 The called endpoint operating the link integrity verification procedures determines the link has failed.
•	The called endpoint physical layer is not established or is out of service.

A.3.3  Receiving a CONNECT message
If a specific DLCI value was requested in the Called party SPVC information element of the SETUP message, then the corresponding CONNECT message must contain the same DLCI value in the Called party SPVC information element coded with the “Assigned DLCI” code point.  If the DLCI values are the same, the calling endpoint signals the PVC is active.  Otherwise the calling endpoint shall release the SPVC with cause No. 21, Call rejected. 

A.3.4  Receiving a RELEASE or RELEASE COMPLETE message
Following reception of a RELEASE or RELEASE COMPLETE, the SPVC connection is cleared.  The connection may be retried.  The clear cause received shall affect the frequency of connection establishment as follows:
• Cause No. 34 No circuit/channel available: Wait a random number of seconds before retry.
• Cause No. 27 (Destination out-of-order):
- If both ends initiate:  
- Do not attempt to retry until a setup message is received for the associated SPVC from the far end, or;
-  optionally, wait a minimum of 60 seconds before retry;
- If single end initiates:  Wait a minimum of 60 seconds before retry;
All other causes:  Perform an immediate retry.

The maximum number of SPVC establishment attempts is a local matter. Upon consecutively receiving the same cause value, the time interval between SPVC establishment should be increased.

A.3.5  Coordination with PVC Signalling procedures
An SPVC endpoint may be coordinated with the PVC UNI procedures of X.36 to exchange status information regarding the operational state of the PVC UNI or an individual virtual connection.  The PVC UNI associated with the SPVC endpoint will operate the network side polling response procedures described in 11.4/X.36.  The PVC UNI may also operate the optional bidirectional procedures described in 11.5/X.36.  When operating the bidirectional procedures the PVC UNI shall provide a polling initiation procedure to obtain status information.
If the procedures of X.36 are used then the following coordination procedures will be provided.

A.3.5.1  PVC addition - Poll response (Network Side) procedures
The following procedures shall be followed when a new SPVC is configured by network management.  The DCE uses the DTE-DCE PVC signalling procedures of X.36 to signal the addition of the new PVC when a STATUS ENQUIRY is received from the DTE.
The PVC signalling procedures of X.36 shall be performed at the calling endpoint when the management entity creates a new SPVC.
If the SPVC is to be established using the “Specific DLCI” or "Specific SPVC correlator” code point, the PVC signalling procedures of X.36 shall be performed at the called endpoint in conjunction with the procedures of A 3.5.3, PVC availability.  This occurs when the management entity configures the called endpoint.  
If the SPVC is to be established using the “Any DLCI” code point, the PVC signalling procedures of X.36 shall be performed when the call is established to the called endpoint in conjunction with the procedures of A 3.5.3.

TABLE A-2/X.76 

SPVC    

New bit generation for SPVCs established with:	New bit is sent in the PVC signalling at the called PVC UNI	
Specific DLCI or Specific DLCI correlator	When the SPVC is configured by network managment	
Any DLCI	When the SPVC call is accepted by the called endpoint	

A.3.5.2  PVC deletion - Poll response (Network Side) procedures
The following procedure will be followed when a SPVC is deleted by network management.  The DCE uses the procedures of 11.4.1.3/X.36 to signal the deletion of the PVC when a STATUS ENQUIRY is received from the DTE.
A PVC is considered deleted for purposes of 11.4.1.3/X.36 when one of the following events occur:
a)	the management entity deletes a SPVC with a configured DLCI at the calling endpoint;
b)	the release of a connection supporting a DLCI value assigned during call establishment at the called endpoint.

A.3.5.3  PVC availability

A.3.5.3.1  Poll response (Network Side) procedures
The following procedures will be followed when SPVC availability changes.  The DCE uses the PVC signalling procedures of X.36 to signal the availability of the PVC when a STATUS ENQUIRY is received from the DTE.
A PVC is active when both DCE interfaces are available as established by the PVC signalling procedures of X.36 and a connection (SPVC) is successfully established between the endpoints.
The calling endpoint shall indicate that a DLCI is active using the procedures of 11.4.1.5/X.36 following receipt of a CONNECT message.  The called endpoint shall indicate that a DLCI is active using the PVC signalling procedures of X.36 following transmission of a CONNECT message.
At the called and calling endpoints of a SPVC established with the “Specific DLCI” or "Specific SPVC correlator” code point, a PVC is considered inactive when the endpoint transmits or receives a RELEASE or RELEASE COMPLETE message.
At the called and calling endpoints of a SPVC established with the “Any DLCI” code point, a PVC is considered deleted when the endpoint transmits or receives a RELEASE or RELEASE COMPLETE message.
Note - When an SPVC which was established with the “Any DLCI” code point is released, the corresponding PVC must be deleted.  This is done to indicate to the user that the DLCI no longer is associated with the same endpoint.

A.3.5.3.2  Poll initiation (User side) procedures
This section applies only when the optional bidirectional procedures of 11.5/X.36 are utilized. The following procedures are applied when a STATUS response is received by the DCE.
When a STATUS response indicates that a PVC  has transitioned from inactive-to-active at the calling PVC UNI, the calling endpoint shall initiate a connection to the called endpoint by sending SETUP message.
If either the calling or called endpoints receive an indication that a PVC is inactive, deleted, or Link Integrity Verification failure, the corresponding SPVC connection (or all SPVCs in the case of Link Integrity Verification failure) will be released (or rejected) by the side receiving the indication with cause No. 27, Destination out of order.
When a RELEASE or RELEASE COMPLETE message is sent by the calling or called party at the interface utilizing bidirectional procedures, and it indicates cause No. 27, Destination out of order, the interface will indicate PVC active to the adjacent network which is attached to that interface.  This ensures that if the PVCs in the adjacent network are configured last, the SPVCs will be triggered to be established by the propagation of the Active bit.

Annex B	

Usage of Cause and Location
Temporary Note - Annex B is to be reviewed in conjunction with a review of Annex E/X.36.Alignment with Recommendatio Q.850 needs to be checked also.

B.1.	 Location field generation

This Annex defines the encoding of the cause value, the location and diagnostic fields of the Cause information element. It also defines the semantics of each cause values to be used for frame relay SVC signalling at the DTE/DCE and NNI  interfaces.

FIGURE B.1/X.76 
Reference configuration for location field generation

TABLE B.1/X.76

Location field values

B.2		Cause Values
The listed cause values are those defined in Recommendation Q.850. They are applicable to different protocols and services. The cause values relevant to frame relay switched virtual circuits are provided below.

Note - Additional Cause values are under consideration for introduction as new causes specific to Recommendation X.76 (and X.36).

Temporary Note - This section will need checking for full alignment with X.36 at the March 1997 SG7 meeting.

Cause value:		No. 1 - Unallocated (unassigned number)
Class (octet 4 bits 7 6 5 ): 	0 0 0
Value (octet 4  bits 4 3 2 1):	0 0 0 1
Definition:	This cause indicates that the called party cannot be reached because, although the number is in a valid format, it is not currently allocated (assigned).
Diagnostic:	Condition 

Cause value:		No. 2 - No route to specified transit network
Class (octet 4 bits 7 6 5 ): 	0 0 0
Value (octet 4  bits 4 3 2 1):	0 0 1 0
Definition:	This cause indicates that the equipment sending this cause has received a request to route the call to a particular transit network which it does not recognize, either because the transit network does not exist or because while it does exist, does not serve the equipment which is sending this cause.
Diagnostic:	Transit network identity

Cause value:		No. 3 - No route to destination
Class (octet 4 bits 7 6 5 ): 	0 0 0
Value (octet 4  bits 4 3 2 1):	0 0 1 1
Definition:	This cause indicates that the called party cannot be reached because the network through which the call has been routed does not serve the destination.
Diagnostic:	Condition

Cause value:		No. 6 - Channel unacceptable
Class (octet 4 bits 7 6 5 ): 	0 0 0
Value (octet 4  bits 4 3 2 1):	0 1 1 0
Definition:	This cause indicates that the channel identified is not acceptable to the sender of this cause value. This cause value is used with an ISDN access.
Diagnostic:	Not defined

Cause value:		No. 7 - Call awarded and being delivered in an establish channel
Class (octet 4 bits 7 6 5 ): 	0 0 0
Value (octet 4  bits 4 3 2 1):	0 1 1 1
Definition:	This cause indicates that the user has been awarded the incoming call and that the incoming call is being connected to a channel already established to that user for similar calls. This cause is used when the frame relay service is accessed through an ISDN circuit mode connection. 
Diagnostic:	Not defined 

Cause value:		No. 16 - Normal call clearing
Class (octet 4 bits 7 6 5 ): 	0 0 1
Value (octet 4  bits 4 3 2 1):	0 0 0 0 
Definition:	This cause indicates that the call is being cleared because one of the users has requested that the call be cleared.
Diagnostic:	Condition

Cause value:		No. 17 - User busy
Class (octet 4 bits 7 6 5 ): 	0 0 1
Value (octet 4  bits 4 3 2 1):	0 0 0 1
Definition:	This cause indicates that the called party is unable to accept another call because a busy condition has been encountered. This cause value may be generated by either the called user or the network.
Diagnostic:	Not applicable the frame relay service

Cause value:		No. 18 - No user responding
Class (octet 4 bits 7 6 5 ): 	0 0 1
Value (octet 4  bits 4 3 2 1):	0 0 1 0
Definition:	This cause indicates that the called user does not respond to a call establishment message within the prescribed period of time allocated.
Diagnostic:	Not defined 

Cause value:		No. 21 - Call rejected
Class (octet 4 bits 7 6 5 ): 	0 0 1
Value (octet 4  bits 4 3 2 1):	0 1 0 1
Definition:	This cause indicates that the equipment sending this cause does not wish to accept this call,  although it could have accepted the call because it  is neither busy nor incompatible.
Diagnostic:	Call rejected condition 

Cause value:		No. 27 - Destination out of order
Class (octet 4 bits 7 6 5 ): 	0 0 1
Value (octet 4  bits 4 3 2 1):	1 0 1 1
Definition:	This cause indicates that the destination cannot be reached because the interface is not functioning correctly. The phrase functioning correctly  indicates that a signaling message was unable to be delivered to the called user.
Diagnostic:	Not defined 

Cause value:		No. 28 - Invalid number format (address incomplete)
Class (octet 4 bits 7 6 5 ): 	0 0 1
Value (octet 4  bits 4 3 2 1):	1 1 0 0
Definition:	This cause indicates that the called party cannot be reached because the called party number is not in a valid format or is not complete.
Diagnostic:	Not defined 

Cause value:		No. 29 - Facility rejected
Class (octet 4 bits 7 6 5 ): 	0 0 1
Value (octet 4  bits 4 3 2 1):	1 1 0 1
Definition:	This cause is returned when a supplementary service requested by the user cannot be provided by the network.
Diagnostic:	Facility identification 

Cause value:		No. 30 - Response to STATUS  ENQUIRY
Class (octet 4 bits 7 6 5 ): 	0 0 1
Value (octet 4  bits 4 3 2 1):	1 1 1 0
Definition:	This cause is included in the STATUS message when the reason for generating the STATUS message was the receipt of a STATUS ENQUIRY message.
Diagnostic:	Not defined 

Cause value:		No. 31 - Normal, unspecified
Class (octet 4 bits 7 6 5 ): 	0 0 1
Value (octet 4  bits 4 3 2 1):	1 1 1 1
Definition:	This cause is used to report a normal event only when no other cause in the normal call applies.
Diagnostic:	Not defined 

Cause value:		No. 34 - No circuit/channel available
Class (octet 4 bits 7 6 5 ): 	0 1 0
Value (octet 4  bits 4 3 2 1):	0 0 1 0
Definition:	This cause indicates that there is no appropriate circuit/channel presently available to handle the call.
Diagnostic:	Not defined 

Cause value:		No. 38 - Network out of order
Class (octet 4 bits 7 6 5 ): 	0 1 0
Value (octet 4  bits 4 3 2 1):	0 1 1 0
Definition:	This cause indicates that the network is not functioning correctly and that the condition is likely to last a relatively long period of time. Immediately re-attempting the call is not likely to be successful.
Diagnostic:	Not defined 

Cause value:		No. 39 - Permanent frame mode connection out of service
Class (octet 4 bits 7 6 5 ): 	0 1 0
Value (octet 4  bits 4 3 2 1):	0 1 1 1
Definition:	This cause is included in a STATUS message to indicate that a permanently established frame mode connection is out-of-service due to equipment.
Diagnostic:	Not defined 

Cause value:		No. 40 - Permanent frame mode connection operational
Class (octet 4 bits 7 6 5 ): 	0 1 0
Value (octet 4  bits 4 3 2 1):	0 1 0 0 
Definition:	This cause is included in a STATUS message to indicate that a permanently established frame mode connection is operational and capable of carrying user information.
Diagnostic:	Not defined 

Cause value:		No. 41 - Temporary failure
Class (octet 4 bits 7 6 5 ): 	0 1 0
Value (octet 4  bits 4 3 2 1):	1 0 0 1
Definition:	This cause indicates that the network is not functioning correctly and that the condition is not likely to last a long period of time. The user may wish to try another call attempt almost immediately.
Diagnostic:	Editor's note: Not provided in Q.850

Cause value:		No. 42 - Switching equipment congestion
Class (octet 4 bits 7 6 5 ): 	0 1 0
Value (octet 4  bits 4 3 2 1):	1 0 1 0
Definition:	This cause indicates that the switching equipment generating this cause is experiencing a period of high traffic.
Diagnostic:	Not defined 

Cause value:		No. 43 - Access information discarded
Class (octet 4 bits 7 6 5 ): 	0 1 0
Value (octet 4  bits 4 3 2 1):	1 0 1 1
Definition:	This cause indicates that the network could not deliver access information to the remote user as requested (sub-address, low layer compatibility,...) as indicated in the diagnostic. It is noted that the particular type of access information discarded is optionally included in the diagnostic.
Diagnostic:	Discarded information element identifier

Cause value:		No. 44 - Requested circuit/channel not available
Class (octet 4 bits 7 6 5 ): 	0 1 0
Value (octet 4  bits 4 3 2 1):	1 1 0 0
Definition:	This cause is returned when the circuit or channel indicated by the requesting entity cannot be provided by the other side of the interface.
Diagnostic:	Not defined 

Cause value:		No. 49 - Quality of service not available
Class (octet 4 bits 7 6 5 ): 	0 1 1
Value (octet 4  bits 4 3 2 1):	0 0 0 1
Definition:	This cause indicates that the requested quality of service (specified in the link layer core parameters information element) cannot be provided.
Diagnostic:	Condition

Cause value:		No. 50 - Requested facility not subscribed 
Class (octet 4 bits 7 6 5 ): 	0 1 1
Value (octet 4  bits 4 3 2 1):	0 0 1 0
Definition:	This cause indicates that the user has requested a supplementary service which is implemented by the equipment which generated this cause, but the user is not authorized to use.
Diagnostic:	Facility identification

Cause value:		No. 57 - Bearer capability not authorized
Class (octet 4 bits 7 6 5 ): 	0 1 1
Value (octet 4  bits 4 3 2 1):	1 0 0 1
Definition:	This cause indicates that the user has requested a bearer capability which is implemented but for which he is not authorized to use.
Diagnostic:	Attribute identity 

Cause value:		No. 58 - Bearer capability not presently available
Class (octet 4 bits 7 6 5 ): 	0 1 1
Value (octet 4  bits 4 3 2 1):	1 0 1 0
Definition:	This cause indicates that the user has requested a bearer capability which is implemented but which is not available at this time.
Diagnostic:	Attribute identity 

Cause value:		No. 63 - Service or option not available, unspecified
Class (octet 4 bits 7 6 5 ): 	0 1 1
Value (octet 4  bits 4 3 2 1):	1 1 1 1
Definition:	This cause is used to report a service or option not available event only when no other cause in the service or option not available class (class 011) applies.
Diagnostic:	Not defined

Cause value:		No. 65 - Bearer capability not implemented
Class (octet 4 bits 7 6 5 ): 	1 0 0
Value (octet 4  bits 4 3 2 1):	0 0 0 1
Definition:	This cause indicated that the equipment sending this cause does not support the bearer capability requested.
Diagnostic:	Attribute identity 

Cause value:		No. 66- Channel type not implemented
Class (octet 4 bits 7 6 5 ): 	1 0 0
Value (octet 4  bits 4 3 2 1):	0 0 1 0
Definition:	This cause indicates that the equipment sending this cause does not support the channel type requested. This cause is used with an ISDN access to the frame relay network. 
Diagnostic:	Not applicable to a non-ISDN access to the frame relay.

Cause value:     No. 70 - Only restricted digital information bearer capability is available
Class (octet 4 bits 7 6 5 ): 	1 0 0
Value (octet 4  bits 4 3 2 1):	0 1 1 0
Definition:	This cause indicates that the calling party has requested an unrestricted bearer service but that the equipment sending this cause only supports the restricted version of the requested bearer capability.
Diagnostic:	Not defined

Cause value:		No. 79 - Service or option not implemented, unspecified
Class (octet 4 bits 7 6 5 ): 	1 0 0
Value (octet 4  bits 4 3 2 1):	1 1 1 1
Definition:	This cause is used to report a service or option not implemented event  only when no other cause in the service or option not implemented class (class 100) applies.
Diagnostic:	Not defined

Cause value:		No. 81 - Invalid call reference value
Class (octet 4 bits 7 6 5 ): 	1 0 1
Value (octet 4  bits 4 3 2 1):	0 0 0 1
Definition:	This cause indicates that the equipment sending this cause has received a message with a call reference which is not currently in use on the UNI.
Diagnostic:	Not defined

Cause value:		No. 82 - Identified channel does not exist
Class (octet 4 bits 7 6 5 ): 	1 0 1
Value (octet 4  bits 4 3 2 1):	0 0 1 0
Definition:	This cause indicates that the equipment sending this cause has received a request to use a channel not activated on the interface. This cause is mainly used when an ISDN circuit mode connection is used to access the frame relay network. This cause is used, for example, when a user has subscribed to those channels on a primary rate interface numbered from 1 to 12 and the user equipment or the network attempts to use channels 13 t o 23.
Diagnostic:	For further study.

Cause value:		No. 87 - User not member of CUG
Class (octet 4 bits 7 6 5 ): 	1 0 1
Value (octet 4  bits 4 3 2 1):	0 1 1 1
Definition:	This cause indicates that the called user for the incoming CUG call is not a member of the specified CUG or that the calling user is an ordinary subscriber calling a CUG subscriber. 
Diagnostic:	Not defined 

Cause value:		No. 88 - Incompatible destination
Class (octet 4 bits 7 6 5 ): 	1 0 1
Value (octet 4  bits 4 3 2 1):	1 0 0 0
Definition:	This cause indicates that the equipment sending this cause has received a request to establish a call which has a compatibility attributes (information element) which cannot be accommodated.
Diagnostic:	(Incompatible) information element identifier

Cause value:		No. 90 - Non-existent CUG
Class (octet 4 bits 7 6 5 ): 	1 0 1
Value (octet 4  bits 4 3 2 1):	0 1 1 1
Definition:	This cause indicates that the specified CUG does not exist. 
Diagnostic:	Not defined 

Cause value:		No. 91 - Invalid transit network selection
Class (octet 4 bits 7 6 5 ): 	1 0 1
Value (octet 4  bits 4 3 2 1):	1 0 1 1
Definition:	This cause indicates that a transit network identification was received which is of an incorrect format as defined in Annex C of Q.931.
Diagnostic:	Not defined

Cause value:		No. 95 - Invalid message, unspecified
Class (octet 4 bits 7 6 5 ): 	1 0 1
Value (octet 4  bits 4 3 2 1):	1 1 1 1
Definition:	This cause is used to report an invalid message event only when no other cause in the invalid message class (class 101) applies.
Diagnostic:	Not defined

Cause value:		No. 96 - Mandatory information element is missing
Class (octet 4 bits 7 6 5 ): 	1 1 0
Value (octet 4  bits 4 3 2 1):	0 0 0 0
Definition:	This cause indicates that the equipment sending this cause has received a message which is missing a mandatory information element.
Diagnostic:	Information element identifier

Cause value:		No. 97 - Message type non-existent or not implemented
Class (octet 4 bits 7 6 5 ): 	1 1 0
Value (octet 4  bits 4 3 2 1):	0 0 0 1
Definition:	This cause indicates that the equipment sending this cause has received a message type it does not recognize either because it is not defined or it is defined but not implemented.
Diagnostic:	Message type

Cause value:    No. 98 - Message not compatible with call state or message type non-existent or not implemented.
Class (octet 4 bits 7 6 5 ): 	1 1 0
Value (octet 4  bits 4 3 2 1):	0 0 1 0
Definition:	This cause indicates that the equipment sending this cause has received a message not expected in the current call state. This cause is also sent when a STATUS message was received indicating an incompatible call state.
Diagnostic:	Message type

Cause value:   No. 99 - Information element/parameter non-existent or not implemented
Class (octet 4 bits 7 6 5 ): 1 1 0
Value (octet 4  bits 4 3 2 1): 0 0 1 1
Definition:This cause indicates that the equipment sending this cause has received a message which includes information element(s) not defined or not implemented. This cause indicates that the information element(s) was (were) discarded and not required to process the message. 
Diagnostic:Information element identifier

Cause value: No. 100 - Invalid information element contents
Class (octet 4 bits 7 6 5 ): 1 1 0
Value (octet 4  bits 4 3 2 1):0 1 0 0 
Definition: This cause indicates that the equipment sending this cause has received an information element which it has implemented; however, the encoding of one or more fields of the information element is not supported or implemented.
Diagnostic: Information element identifier

Cause value: No. 101 - Message not compatible with call state
Class (octet 4 bits 7 6 5 ): 1 1 0
Value (octet 4  bits 4 3 2 1):0 1 0 1
Definition:This cause indicates that a message has been received which is incompatible with the call state.
Diagnostic:Message type 

Cause value:No. 102 - Recovery on timer expiry
Class (octet 4 bits 7 6 5 ): 1 1 0
Value (octet 4  bits 4 3 2 1):0 1 1 0
Definition:This cause indicates that a procedure has been initiated by the expiry of a timer in association with error handling procedures.
Diagnostic:	Timer number

Cause value:		No. 111 - Protocol error, unspecified
Class (octet 4 bits 7 6 5 ): 	1 1 0
Value (octet 4  bits 4 3 2 1):	1 1 1 1
Definition:	This cause is used to report a protocol error event only when no other cause in the protocol error class (110) applies.
Diagnostic:	Not defined

Cause value:		No. 127 - Interworking, unspecified
Class (octet 4 bits 7 6 5 ): 	1 1 1
Value (octet 4  bits 4 3 2 1):	1 1 1 1
Definition:	This cause indicates that there has been interworking with a network which does not provide causes for actions it takes. Thus, the precise cause for a message which is being sent cannot be ascertained.
Diagnostic:	Not defined

B.3		Coding of the diagnostic field
B.3.1-Coding of Condition
The condition diagnostic (octet 5) is coded as follows:
	Bit
	 8 
	 1

	Bits
	7 6 5 
	0 0 0 

	Bit	
	 4
	0			network service provider
	1			network service user

	Bit	
	 3
	 0			Normal 
	 1			Abnormal

	Bits
	 2 1
	 0 0			Unknown
	 0 1			Permanent
	1 0 			Transient

B.3.2 Coding of Transit network identity
The diagnostic field contains the entire transit network selection information element.

B.3.3 Coding of call rejected diagnostic
The format of the diagnostic field for cause number 21 is shown in Figure 
B-2/X.76

FIGURE B-2 /X.76
Coding of diagnostic field for cause number 21

TABLE B-2/X.76
Coding of diagnostic field for cause number 21

Rejection reason (octet 5)
	Bits 
	7 6 5 4 3 
	0 0 0 0 1 		Information element missing 
	0 0 0 1 0		Information element contents are 
                   			not sufficient
	All other values are reserved

Condition (octet 5)
	Bits
	2 1 
	0 0			Unknown
	0 1			Permanent
	1 1  			Transient

IE type (octet 7)

 8
 0   Variable length information element
 1   Fixed length information element

IE identifier (octet 7)

Bits 7-1 are encoded with the information element identifier of the missing or insufficient information element (See section 10.5 for the information element code     values).

B.3.4 Coding of timer value
The timer number is coded using characters defined in Recommendation T.50, one character per decimal digit. The following coding is used in each octet starting with octet 5 of the  diagnostic field:

Bit 8: Spare B'0'
Bits 7-1: IA5 character

NOTE: The most significant decimal digit of the timer is coded first (in octet 5), the other digits are coded in subsequent octets.

B.3. Coding of message type
The message type is coded as specified in clause...

B.3.6 Coding of the facility type
for the simple CUG since it is not possible to code the code point of an information element. The code point of the information element associated with the facility rejected. Except

Appendix VI

International identifiers for networks providing frame relay services and numbered under the E.164 numbering plan

(This appendix does not form an integral part of this Recommendation)

VI.1	Introduction  
For those public frame relay networks numbered under the E.164 numbering plan, the International identifier will consist of the E.164 Country Code followed by a network identifier code. The maximum length of the International identifier is 8 octets code according to Recommendation T.50. Only numeric values (0-9) shall be used.

Whilst the assignment of these network identification codes is a national matter, regular publication of such information is required to be made available to both users and operators of public frame relay networks. Accordingly this appendix outlines the procedure for the assignment by a national authority, and notification to the ITU-T of the allocated network identification codes, in order that this information can be maintained in a central register and be published on a regular basis.

VI.2	Assignment and notification process
The assignment of network identification codes to frame relay networks numbered under the E.164 numbering plan, in order to create an International identifier, is a purely national matter and will be made by a national authority in accordance with national laws and regulations or agreed national arrangements. The allocating authority will notify the ITU TSB of any new or revised assignments. Assignments of frame relay network identification codes will be published in the ITU operational Bulletin. A recapitulatory list is published annually in the Operational Bulletin. 

______________________________